query cache被官方最终放弃的双重原因：全局锁争用+缓存效果本身不好

MySQL的query cache（查询缓存）功能从默认开启逐步走向默认关闭，最终官方开发组还计划在8.0版本里彻底移除它，这个转变背后有两个叠加的原因。第一个原因是并发瓶颈：访问query cache需要获取一个全局锁，在高并发场景下，这个全局锁本身会成为严重的争用点——大量并发请求都要竞争这同一把锁才能读写缓存，锁竞争带来的开销随着并发量上升而急剧放大，反而拖累了整体性能。第二个原因更根本：query cache本身缓存命中的实际效果并不理想——这个缓存机制要求SQL语句完全一致（哪怕一个空格、大小写的差异都会导致缓存失效）才能命中，而且表数据只要发生任何写入变更，相关的缓存条目就要全部失效，这在真实业务场景（表数据经常变化）下会导致缓存频繁被清空重建，实际能真正发挥效果、省下重复查询开销的场景比想象中少得多。这两个原因叠加起来的结论是：query cache花费了”引入一把全局锁”这个实实在在的并发代价，换来的却是名不副实的缓存收益，整体上是弊大于利的，这也是为什么MySQL官方最终选择关闭并计划移除它。这个案例给出了一条评估任何”缓存机制”是否值得启用的重要原则：一个缓存机制的价值，不能只看它理论上”能不能加速重复查询”这个表面逻辑，还要具体审视两件事——这个缓存机制本身的读写访问是不是引入了新的并发瓶颈（这里是全局锁），以及在真实的业务写入模式下，这个缓存实际的命中率能有多高（如果数据更新频繁、缓存条目频繁失效，命中率会大打折扣）；只有当”缓存本身的开销”明显小于”它实际能节省的开销”时，引入这个缓存机制才是划算的，否则很可能像query cache这样，成为一个理论上美好、实际上得不偿失的设计。