MySQL的缓存到底有多少种这个问题我问过不少同行答案五花八门有人脱口而出查询缓存有人会提到InnoDB Buffer Pool还有人直接说用Redis。其实这些答案都对但都不完整。MySQL的缓存体系从来就不是某一层的事而是一套从存储引擎到SQL层、再到业务层的组合拳。把这套组合拳打明白了查询效率才能真上一个台阶。这篇内容我不讲空泛的性能优化方法论就实打实拆一遍MySQL缓存家族里每个成员的工作原理、适用场景、配置参数以及我这些年踩过的坑。适合谁看手里管着MySQL 5.7或8.0被慢查询折磨过或者准备给系统加缓存却又担心数据不一致的同学这篇内容应该对你有用。我会尽量把原理、实操抄作业级别的细节都覆盖到。1. 先看清楚MySQL缓存的大盘面1.1 缓存为什么是查询效率的胜负手理解缓存之前得先明白一个物理事实磁盘的随机读写速度通常只有内存的千分之一。MySQL的数据最终都存在磁盘上但用户查询不可能每次都去磁盘上翻页——真要那样一个几千万行的表一次全表扫描就得让CPU干等好几秒。缓存的本质就是空间换时间把这部分高频访问的数据提前复制一份到更快的存储介质里。MySQL里最典型的介质差就是内存 vs 磁盘。你往innodb_buffer_pool_size里多分配1GB内存相当于多建了一个小型数据热柜让InnoDB把最常访问的数据页直接放在热柜里等用户来取。这里有个很容易混淆的点MySQL的缓存不是一个东西而是好几种东西叠加在一起。如果你只盯着某一个缓存层调参效果往往有限甚至可能适得其反。就好比给家里的暖气片烧得滚烫但是窗户大敞着屋里的热量照样留不住。缓存链路里每一环都得搭配着看。1.2 MySQL缓存家族的全景图谱我按数据流的走向把MySQL相关的缓存分成了四层缓存层所处位置核心作用典型代表存储引擎缓存InnoDB内部缓存数据页、索引页、undo日志页Buffer Pool、Change Buffer、Log BufferSQL层缓存MySQL Server层缓存SQL语句的执行结果查询缓存8.0已移除客户端/框架缓存应用与数据库之间缓存Mapper方法级别的查询结果MyBatis一级/二级缓存分布式缓存应用层独立部署缓存热点数据扛高并发读Redis、Memcached第一层是MySQL自身的大动脉。InnoDB Buffer Pool承载了绝大部分MySQL原生缓存的使命后面会重点讲。第二层查询缓存已经成了历史但搞清楚它为什么被淘汰对理解后续缓存设计非常有帮助。第三层和第四层严格说不在MySQL内部但它们直接决定了打到MySQL上的查询量所以搞MySQL优化的人不可能绕开它们。这四层缓存不是替代关系而是各管一段。Buffer Pool管的是数据页从磁盘到内存的搬运Redis管的是最终查询结果不要每次都回数据库取。把它们当成一个流水线来看就知道该在哪个环节加料了。2. 查询缓存被时代淘汰的“小猪存钱罐”2.1 查询缓存的工作原理MySQL 5.1之前的版本就在Server层内置了查询缓存。它的逻辑非常直白把SELECT语句的SQL文本做哈希如果缓存里有对应结果集就直接返回不再进入解析、优化和执行阶段。听起来是不是很完美SQL一样、表数据没变结果集直接复用这不是白捡的性能吗但问题出在SQL一样这四个字上。查询缓存的匹配规则是全字符匹配多一个空格、大小写不同、注释里有差异哈希就对不上。更夸张的是SELECT * FROM t WHERE id 1和SELECT * FROM t WHERE id1是两条完全独立的缓存项。也就是说线上SQL如果不强制规范书写查询缓存的命中率会低到让你怀疑人生。我用过一个比较极端的例子一张只有几千行的配置表短时间被高频查询开启查询缓存后确实能做到毫秒级返回。但一旦表里数据变了所有关联该表的查询缓存全部失效下一次请求又得重新查。这种一次性买卖的缓存在数据频繁更新的业务场景下几乎就是摆设。2.2 为什么说它是隐形的性能杀手查询缓存最坑的地方不是命中率低而是它引入了全局锁竞争。在MySQL 5.7及之前的版本查询缓存的访问和失效操作都牵扯到一把全局锁。所有查询在读取缓存结果前要加锁写操作在使相关缓存失效时也要加锁。当你的系统写多读少每次UPDATE都要把涉及表的所有查询缓存清一遍这个清的动作本身就在和SELECT抢锁。网上有很多案例同样的业务量关闭查询缓存后数据库压力反而下降。我自己的经历也印证了这一点。当时我负责一个后台管理系统数据变更频繁查询缓存开启后性能不仅没提升反而出现了一堆Waiting on query cache mutex的线程堆积。把query_cache_type改成OFF之后等待线程瞬间消失整体吞吐还涨了。到了MySQL 8.0官方直接把查询缓存整个模块删掉了。这不是拍脑袋的决定而是因为他们也意识到在InnoDB已经成为默认引擎、Buffer Pool机制日趋成熟之后查询缓存的收益已经远小于它带来的锁开销和内存碎片。2.3 如果你还在用5.7怎么处理查询缓存还在跑MySQL 5.7的同学我建议直接关掉查询缓存把内存留给InnoDB Buffer Pool。# my.cnf 中查询缓存相关配置 query_cache_type OFF query_cache_size 0重启MySQL后用下面的SQL确认状态SHOW VARIABLES LIKE query_cache%;所有query_cache_*变量都处于完全关闭状态才算干净。有些教程会让你设置query_cache_type DEMAND配SQL_CACHE提示词按需缓存但我的经验是除非你对业务SQL有绝对控制权并且深入分析过每条语句的缓存收益否则这个方案执行起来成本太高收益又很鸡肋。5.7用户别指望这个老古董替你扛读压力把精力放到Buffer Pool上才是正道。3. InnoDB Buffer Pool真正该花的心思都在这里3.1 Buffer Pool到底在缓冲什么InnoDB把数据组织成一个个16KB大小的页。InnoDB Buffer Pool就是内存里的一片区域用来存放这些从磁盘读出来的页。这个描述听着简单但它的内部结构一点也不简单。Buffer Pool里不仅放普通的数据页还放索引页、插入缓冲Change Buffer、锁信息Lock Info、自适应哈希索引等。我们执行一次SELECTInnoDB会先在Buffer Pool里找需要的页找不到才去磁盘读读完之后页会留在内存里供下次使用。这个机制跟你手机看视频边看边缓存是一个道理——第一次慢后面快。这里有个必须提的点当你执行UPDATE时修改的不是磁盘上的数据而是Buffer Pool里的内存页。之后通过后台线程把脏页刷到磁盘或者等内存不足时强制刷盘。很多人问为什么MySQL改了配置后磁盘占用没变化答案就在这里——真正的变更发生在内存里落盘本来就有延迟。3.2 关键参数怎么配Buffer Pool的大小和实例Buffer Pool是InnoDB缓存的核心也是最值得优先调优的参数。我的经验是OLTP场景下Buffer Pool至少给到物理内存的60%。如果你机器是64GB内存MySQL独占那innodb_buffer_pool_size设成40GB是比较合理的起点。但如果机器上还有别的服务就得留出余量别把内存吃满导致操作系统开始swap那比缓存不够还致命。[mysqld] # 单实例独占机器时可参考物理内存的60%~70% innodb_buffer_pool_size 40G # 8.0之后的推荐配置用这个命令可以免重启调整 # SET GLOBAL innodb_buffer_pool_size 40G;Buffer Pool不是一块整肉。从5.7开始它默认拆分为多个实例每个实例由独立的线程管理减少并发时的锁竞争。建议把innodb_buffer_pool_instances设置为CPU核心数或8取较小值。比如16核机器设8个实例每个约5GB基本能压榨出这套缓存系统的并发潜力。3.3 命中率怎么算怎么看配置配好了怎么知道缓存到底起了多大作用看命中率。核心指标来自SHOW GLOBAL STATUSSHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read%;重点关注两个值Innodb_buffer_pool_read_requests从Buffer Pool中读到的请求次数。Innodb_buffer_pool_reads真正落到磁盘读的次数。命中率公式是命中率 (read_requests - reads) / read_requests我一般要求线上系统这个数值保持在95%以上。如果低于90%说明Buffer Pool容量不足或者存在大量全表扫描缓存页被频繁淘汰。还有一个容易忽略的指标——Innodb_buffer_pool_wait_free如果这个值持续增长说明有线程在等待空闲缓存页通常意味着Buffer Pool太小或刷脏速度跟不上这时候光加内存还不够还要检查innodb_io_capacity和innodb_io_capacity_max这两个参数决定了InnoDB每秒最多能刷多少个脏页。SSD环境可以适当调高到2000左右。3.4 缓存预热与后备军把“冷启动”变成“热启动”数据库重启后Buffer Pool是空的业务流量一进来所有查询都先走磁盘短期内延迟会明显飙高。与其干等缓存慢慢加热不如主动预热。MySQL 5.7和8.0都提供了Buffer Pool的持久化功能[mysqld] innodb_buffer_pool_dump_at_shutdown 1 innodb_buffer_pool_load_at_startup 1这两个参数的意思是关闭MySQL时把当前Buffer Pool中的热数据页信息只是一份页ID列表占用空间很小记录到磁盘文件ib_buffer_pool启动时再按这份列表把对应的页提前读入内存。我的实践经验是重启后冷启动的预热时间基本能缩短一个数量级。比如一个80GB的Buffer Pool不预热可能要十几分钟才能恢复高命中率有了dump/load机制两三分钟内就能回到正常水平。还有一个小技巧在业务低峰期手动跑一遍SELECT COUNT(*) FROM 大表这类全表操作把这批热页刷进Buffer Pool等高峰期来临时命中率就已经很可观了。注意别在业务高峰期做这种事那等于往已经满负荷的系统里再倒一桶水。4. 业务层缓存把压力挡在数据库门外4.1 为什么单靠MySQL内部缓存仍然不够Buffer Pool再大也扛不住极端的热点场景。一个典型问题某条爆款商品信息在直播间被几千人同时请求同一个查询请求打到MySQL上千次Buffer Pool虽然能提供页级别的缓存但每次查询依然要经过SQL解析、权限检查、事务管理和网络传输这些开销省不掉。更麻烦的是有些查询涉及多表JOIN和复杂计算即便数据全在内存里单次执行也要十几毫秒。如果业务要求接口响应在20ms以内那么这条查询就是瓶颈。这种情况下唯一解就是把最终结果缓存到离用户更近的地方——应用内内存或者Redis让大部分请求根本到不了MySQL。我一直跟团队强调一句话MySQL的缓存是保底用的业务层的缓存才是扛量用的。真正的高并发系统数据库只应该处理那些缓存覆盖不到的部分。4.2 缓存更新的标准姿势Cache Aside模式业务层缓存最常见的坑不是没加缓存而是加了缓存之后数据和数据库对不上。我这里只推荐一种经过了大量实践检验的模式Cache Aside。Cache Aside的流程是读请求先读Redis命中就直接返回没命中就查数据库拿到结果后写回Redis再返回给调用方。写请求先更新数据库再删除对应的Redis缓存key。注意写操作是先更新DB再删缓存不是先更新缓存。这里面的道理值得展开说。如果先更新缓存再更新DB一旦DB更新失败缓存里就是新数据、DB里还是旧数据不一致反过来先更新DB再删缓存即使删缓存失败最多是旧缓存多存活一段时间下次读请求依然会重新加载。相比之下后者的风险窗口要小得多。删除缓存和更新DB之间有个极小的时间窗口理论上可能出现请求A更新DB请求B读旧缓存然后请求B把旧数据写回缓存的情况。业界有延迟双删的补救方案更新DB后删一次缓存隔几百毫秒再删一次保证把并发期间可能写回的旧缓存清掉。实操中我建议在缓存key上附加版本号比如商品详情用product:detail:1001:v3每次更新DB就换一个新版本号天然绕开了旧数据写回的脏读问题。4.3 缓存穿透、击穿、雪崩的实战解法加了Redis之后读多写少的瓶颈一下子松了但马上会碰到三座大山穿透、击穿、雪崩。我用大白话解释并给出解法。穿透指的是查询一个根本不存在的数据比如用一个随机的负数ID查用户Redis里没缓存数据库里也没数据每次请求都直接怼到DB上。恶意攻击经常会利用这一点。解法通常是两个一是对空结果也做短时间缓存比如缓存一个null占位符过期时间60秒二是在查询前用布隆过滤器快速过滤掉肯定不存在的ID。布隆过滤器理解起来不难它用多个哈希函数把一个ID映射到一段bit数组上判断ID一定不存在非常快代价是有极小的误判率会把存在的也判成不存在。击穿指的是热点key突然过期失效大量并发请求同时落到数据库上。比如一个秒杀商品的缓存过期了一瞬间几万请求穿透过来。解法是加互斥锁缓存未命中时只允许一个线程去查库其他线程等待结果并共享。Redis里可以用SET NX命令实现简单的分布式锁。雪崩是大面积的缓存同时失效。比如所有缓存key的过期时间都设置成相同的1小时那每到整点就会出现一次请求洪峰。解法很简单过期时间加随机抖动过期时间 固定值 随机(0, 300秒)把失效时间打散避免集体殉爆。实际上这三座大山很多团队都处理过但真正容易忽略的是日志监控。我见过不少项目Redis挂了完全没人发现直到数据库被拖垮才排查出来。建议对Redis的命中率、慢查询、连接数做基础告警命中率低于阈值就要立刻关注。4.4 一致性翻车现场从延迟到最终一致做缓存最难过的一关永远是数据一致性。很多刚入门的新人默认缓存和DB必须完全同步但分布式系统里想要强一致基本等于放弃缓存。大型互联网系统普遍接受的方案是最终一致允许短时间内不一致但保证最终缓存里的数据会和DB对齐。要达成最终一致除了Cache Aside之外还有几个辅助手段值得沉淀给缓存设置合理的TTL即使删缓存失败TTL一到也会强制刷新。生产环境可以用消息队列消费DB的变更日志比如监听binlog变更拿到变更事件后去更新或删除对应缓存。这种方案把业务主动删缓存变成了数据层自动通知减少业务代码侵入。定期做对账任务抽查Redis里的key和DB里对应的数据是否一致。我自己踩过一个比较深的坑当时业务代码里更新DB后删缓存这个动作里删缓存使用的是不带过期时间的DEL操作结果网络抖动导致删缓存失败缓存里就一直保留着旧数据。后来我们给所有缓存key强制加上TTL兜底同时引入了MQ异步重试删除这个问题才算彻底解决。5. MyBatis缓存一个被误用最多的“减肥药”5.1 一级缓存默认开启却没人注意的真相如果你在Java项目里用MyBatis那你其实已经被缓存包围了只是很多时候你没意识到。MyBatis的一级缓存是默认开启的作用范围是SqlSession。同一个SqlSession里执行两次完全相同的查询第二次不会真查数据库而是直接返回第一次的结果。这本来是好事能省一次数据库往返但它有个极度隐蔽的坑一级缓存默认是本地Map如果两次查询之间数据被其他事务改了你的第二次查询读到的还是第一次的旧数据。在Spring管理的事务里一个SqlSession往往和整个事务同生命周期意味着你在一个事务里查了一次数据再查第二次时可能拿到脏值。我在一个报表项目里就遇到过同一个事务里先查了汇总数据后面代码里insert了一条新记录再查一次汇总结果数字完全没变。排查了半天才发现是一级缓存捣的鬼。因为MyBatis对UPDATE、INSERT、DELETE会清空一级缓存但前提是这些操作也在同一个SqlSession里且被MyBatis感知到。如果数据是被其他系统改的MyBatis根本不会知道。5.2 二级缓存分布式环境下请你谨慎开启二级缓存是Mapper级别的同一个namespace下的查询结果可以被多个SqlSession共享。理论上它能显著减少数据库压力但我在多数项目里是不建议开启的。原因有两个。第一二级缓存默认存在应用本地内存里如果你的应用是多节点部署每个节点各缓存一份节点之间完全没有同步机制。节点A更新了数据库并清了自己的本地缓存节点B上的缓存还是旧的用户请求被负载均衡到B节点就拿到脏数据。第二二级缓存对查询结果如何序列化非常敏感。如果你的实体类没有实现Serializable或者查询结果里包含动态的List、Map、自定义对象很容易在缓存读写时报错。调试这种问题比直接改查询慢得多。如果项目是单机部署、读多写少、对一致性要求不苛刻二级缓存确实能省一些数据库开销。但我的原则只有一句多节点下的本地二级缓存等于默认接受了不一致。5.3 用了Redis之后MyBatis缓存还有必要吗当系统已经引入了Redis作为业务缓存层MyBatis的二级缓存就显得比较鸡肋了。原因很直接Redis缓存的覆盖范围更大缓存命中后连MyBatis都不需要进入而MyBatis二级缓存还在应用进程内部数据本质上和应用进程强绑定。两者并存还会产生一条尴尬链路应用查Redis未命中进入MyBatis时命中了本地二级缓存拿到旧数据后写回Redis结果把Redis里的新数据也覆盖成了旧数据。这个组合坑我不止一次在同事的代码里看到过。我的建议是如果已经在用Redis做业务缓存直接把MyBatis二级缓存关掉减少一层不可控的中间状态。一级缓存保留没有问题但要意识到它的存在跨事务查询时不要依赖它的正确性。6. 高频问题与排查实录6.1 缓存命中率上不去先查这四件事如果你发现Buffer Pool命中率低别急着加内存先按顺序排查是不是存在大量未加索引的全表扫描全表扫描会把大量用不到的页读进Buffer Pool挤掉热数据。EXPLAIN看一遍慢查询重点找type ALL的记录。是不是表太大而Buffer Pool太小检查SHOW GLOBAL STATUS里的Innodb_buffer_pool_bytes_dirty如果脏页占比长期很高说明内存里积累了太多待刷盘的页。是不是有周期性任务导致缓存冷启动比如凌晨的批量跑批任务会全表扫描大表把Buffer Pool的热数据冲掉早上上班高峰期命中率自然难看。解决办法是把跑批放在业务低峰期或在跑批结束后执行一次预热。是不是SQL写法导致缓存利用不充分SELECT *会把整行所有列都读进内存而业务往往只需要两三个字段。改成只查需要的列不仅网络传输变少Buffer Pool的页也能容纳更多有效数据行。6.2 缓存和数据库不一致一个真实复工案例有次做电商订单详情优化上线后出现了一个诡异问题用户下单后接口返回的订单状态偶尔还是待支付刷新一下又正常了。我们定位到订单详情已经加了Redis缓存下单后理应更新DB并删除缓存但状态偶尔不对。排查过程拉锯了很久最后发现是这行代码的时序问题// 错误示范先删缓存再更新DB redisTemplate.delete(order:detail: orderId); orderMapper.updateStatus(orderId, status);如果删缓存之后、更新DB之前有另一个线程来查数据它会查到DB里的旧状态然后把旧状态写回Redis。后续的请求就都命中这个脏缓存了。这正好就是前面提到的Cache Aside里先更新DB再删缓存原则的价值体现。我们把代码顺序改成先更新DB再删缓存并给缓存key加了订单版本号后缀之后问题彻底消失。6.3 一条SQL从3秒到50毫秒的复合优化实录最后分享一个综合案例。一个后台报表查询要关联三张表每次执行要3秒左右业务方天天抱怨。我当时的优化路径是这样的第一步EXPLAIN发现主表的驱动查询没用上索引走了全表扫描。加了联合索引后查询耗时从3秒降到800毫秒。第二步观察Buffer Pool命中率发现只有82%左右。原因是这个报表查询每次扫的数据量很大而且数据日期跨度管三年。我们把查询条件改成优先查最近三个月同时调整了Buffer Pool实例数命中率提升到96%耗时进一步降到300毫秒。第三步分析业务发现这个报表的聚合结果对实时性要求不高于是用Redis做了结果集缓存TTL设10分钟加了名称里提到的随机过期时间防雪崩。之后接口响应稳定在50毫秒以内。这个案例能说明一个道理优化缓存从来不是单纯调一个参数而是索引、内存、缓存策略、业务时效性综合博弈的结果。先让SQL本身高效再用缓存把高效的结果留住这条路对大多数系统都适用。我自己在实际项目里最大的体会是不要神化缓存也不要轻视缓存。它是最直接的性能杠杆但用不好也会成为数据一致性的重灾区。把Buffer Pool当成基本功把Redis当成容量扩展工具把MyBatis缓存当成需要谨慎对待的补充你手里的这套组合方案才能真正扛住流量。