缓存可能看起来像是一种简单，快速的解决方案，因为可以轻松进行部署，而不会在数据库扩展或恶化，数据库模式重新设计甚至更深层次的技术转换方面花费大量成本。
缓存独立于数据库，而应用程序负责缓存的一致性。该应用程序对缓存和数据库执行两次写入。读取首先从缓存中完成，并且只有当数据不存在时，才会对数据库进行单独的读取，可以想象，有关一致性，高可用性和复杂性的问题立即出现。
1.外部缓存会增加延迟
单独的缓存意味着途中的另一跳。当缓存围绕数据库时，第一次访问发生在缓存层。如果数据不在高速缓存中，那么请求将发送到数据库。结果是未缓存的数据本来就很慢的路径会有额外的延迟。有人可能会说，当整个数据集都适合缓存时，不会产生额外的延迟，但是在大多数情况下，不止一个工作负载/模式会影响数据库，而且某些工作负载/模式会带来额外的跃点成本。
2.外部缓存是额外的费用
缓存意味着DRAM，这意味着每GB的成本高于SSD / HDD。在额外的RAM可以存储经常访问的对象的情况下，最好利用现有的数据库RAM，并可能增加它，以便将其用于内部缓存。在其他情况下，工作集大小可能太大，某些情况下达到PB，因此首选另一种SSD友好实现。
3.外部缓存会降低可用性
缓存的高可用性(HA)解决方案通常不如数据库自己的HA。现代的分布式数据库具有多个副本。它们还了解拓扑和速度，并且可以承受多个故障。
例如，Scyla中的常见复制模式是三个本地副本，并且确认的回复需要仲裁。此外，副本位于远程数据中心，可以查阅。
缓存不具有良好的高可用性属性，并且很容易发生故障，或者具有部分故障，这在一致性方面会更糟。当缓存失败(并且所有组件注定要在某个时刻失败)时，数据库将达到全吞吐率，您的SLA和对最终用户的保证将不满意。
尽管DAX设计和实现是专有的，但我倾向于相信DAX开发人员不会损害可用性，但是很难说出在三个可用性区域中会发生什么。
4.应用程序复杂性–您的应用程序需要处理更多情况
复杂性当然不是DAX的情况，而是适用于标准外部缓存。有了外部高速缓存后，您需要使高速缓存与客户端和数据库保持最新。例如，如果您的数据库运行修复，则需要同步(或使缓存无效)。您的客户端重试和超时策略需要匹配缓存的属性，但是还需要在缓存完成后起作用。通常，这种情况很难测试。
5.外部缓存破坏了数据库缓存
现代数据库具有内部缓存和用于管理其缓存的复杂策略。当您将缓存放置在数据库的前面时，大多数读取请求将仅到达外部缓存，而数据库不会将这些对象保留在其内存中。结果，数据库高速缓存无效，并且当请求最终到达数据库时，其高速缓存将变冷并且响应将主要来自磁盘。
6.外部缓存不安全
同样，安全性不是DAX的问题。但是自然地，对缓存中放置的数据的加密，隔离和访问控制可能与数据库层本身的加密，隔离和访问控制不同。
7.外部缓存会忽略数据库知识和数据库资源
数据库非常复杂，并在系统上增加了磁盘I / O工作量。任何查询都访问相同的数据，并且可以将一定数量的工作集大小缓存在内存中，以节省磁盘访问。一个好的数据库应该具有多种复杂的逻辑，以决定应该缓存哪些对象，索引和访问。
数据库还应具有各种驱逐策略(以最近使用最少的策略为例)，以确定新数据何时应替换现有的较早缓存对象。另一个示例是抗扫描缓存。扫描大型数据集时，会从磁盘读取或触摸缓存中的许多对象。数据库可以意识到这是扫描而不是常规查询，因此选择将这些对象保留在其内部缓存之外。
数据库自动将缓存的内容与磁盘以及传入的请求进行同步，因此用户和开发人员无需执行任何操作即可使它发生。
