最近，Oracle的产品管理总监在Oracle数据库内幕中介绍了True Cache。
原文链接如下：
由于这篇文章比较火爆，我们国内已经有很多的数据库爱好者完整的翻译这篇文章，所以笔者也不需要重复翻译，本文旨在提炼文中关键信息，并使用大白话和大家一起探讨下23ai中的True Cache功能：
通常这个问题会是IT部门的领导层最关心的问题，现有架构下，为什么需要引入True Cache？
回答这个问题，需要先了解下目前的发展趋势，当下随着数字化环境的不断发展，各类应用要求提供实时响应成为当务之急，而大家都知道数据库的资源很宝贵，大部分高并发应用其实都是读多写入的场景，所以业界常用的方案就是在数据库的前面加一个缓存层，且将它设计在内存中缓存（Caching），这个底层逻辑其实也非常简单，就是内存的速度一定是远远高于存储速度的，这是介质本身存在的数量级的性能差异。
当然，能接受用缓存的共识是这个缓存中无需最新的数据，说白了，无论你用什么样的缓存技术，读的数据无论多少，一定都是有延迟的，可应用需求一定会要求这个延迟越小越好，这里原文中立马就提到Oracle提供的True Cache是一个突破性的缓存解决方案，那这个突破性具体体现在哪里呢？
这些方面的优势是因为True Cache相当于是一个主库的全功能的只读副本，类似ADG，但又比ADG轻量，它不需要数据文件的存储，别小看这一点，对于当下一个动辄几十T数据量的数据库来说，将会是非常大的成本节约。
这里，提炼文中关键的几点：
文中提到了两种方式：
这里多个物理连接不用多说，主要优势点还是在于支持提供一个逻辑连接，然后通过Driver处理底层的物理连接，这就可以真正的简化应用配置。
True Cache的好处体现在：
应用场景文中提到的可以给大家参考：
这些点大部分都比较好理解，也可以作为我们发现更多应用场景的一个启发。
不过最后这点“数据主权”的应用场景，笔者其实也是有一些疑问的，因为如果单纯使用True Cache技术，即便True Cache部署在特殊地区，数据其实都还在主库中，只是这个True Cache接受到的用户请求没有出境而已。如果要做到真正的数据主权，应该是还要配合Sharding技术。大家觉得呢？
最后总结部分，文中提到Oracle的True Cache是全面的解决方案，再次强调原生的Ture Cache能同时利用到Oracle DB的完整能力，这个其实也是所有Oracle原生技术的通用优势了，比较容易理解。