数据库变慢的时候大多数人的第一反应是什么加索引或者加机器。但很多时候你还没到需要升级硬件那一步。MySQL本身的缓存策略就没配置到位大量的热数据根本没被有效地留在内存里磁盘IO成了瓶颈SQL再优化也快不起来。我做了这么多年数据库相关的开发和运维几乎每次性能排查走到最后都会落到缓存策略上。今天这篇就把MySQL缓存这条线从头到尾捋一遍——从它内部的Buffer Pool到已经进了历史课本的Query Cache再到业务系统真正常用的应用层缓存方案都聊透。这篇东西适合谁看一类是刚接手项目、发现数据库CPU和磁盘IO经常报警的后端开发另一类是准备面试、经常被问到MySQL缓存机制和优化思路的求职者。读完你至少能搞清楚MySQL有哪些层级的缓存、每个缓存该调到多大、缓存命中率怎么计算、以及为什么现在的互联网项目基本都在应用层再做一道缓存。除了原理我还会把实际运维中踩过的坑和排查手段一并写出来。1. MySQL缓存体系先看清“房子”里有哪些抽屉1.1 从内存视角重新认识MySQL我们平时聊MySQL优化总是习惯性先看慢查询日志、再看SQL执行计划这当然没错。但如果对MySQL的内存工作方式没概念很多优化做起来就是隔靴搔痒。MySQL其实是一个典型的“吃内存”的数据库它把数据放在磁盘上但读写都尽量在内存里完成。你可以把MySQL的内存想象成厨房里的操作台——菜都放在冰箱磁盘里但做菜的时候你不会一趟趟跑冰箱而是把常用的食材和工具提前摆到操作台上。缓存策略本质上就是决定怎么摆这个操作台、摆多少东西上去。MySQL的缓存分散在好几个层级。最底层的是操作系统的文件缓存只要你不强制开启innodb_flush_methodO_DIRECT绕过它系统会自动把热点的数据文件页缓存起来。再往上是MySQL自身各存储引擎和Server层的缓存。InnoDB引擎有Buffer Pool、Log BufferMyISAM引擎有Key BufferServer层曾经还有Query Cache还有表结构缓存、线程缓存、排序缓冲、连接缓冲等等一堆东西。这么多缓存在实际排障时优先级是完全不同的。我自己看一个MySQL实例99%的精力都花在InnoDB Buffer Pool上偶尔看下Log Buffer和表缓存。其他的缓存要么影响面太小要么在8.0版本已经彻底删掉了。理解这层关系很重要——缓存优化不是把每个参数都调一遍而是盯住最核心的瓶颈点。1.2 哪些缓存值得你花时间去调我在这直接把两类缓存摊开讲清楚一类是值得死磕的一类是基本别碰的。值得花心思的首推InnoDB Buffer Pool。它负责缓存数据页、索引页、插入缓冲、锁信息等是InnoDB读写数据的主要中转站。你可以把它看作是数据库的“主存工作区”几乎所有热数据的读写都经过它。如果这个池子太小热数据根本放不下每次查询都得走磁盘那性能必然稀碎。相关的配置参数也很多包括大小、实例数、预热方式、刷脏策略等等。其次是Log Buffer也就是重做日志缓冲。它负责暂存事务提交时产生的redo log避免每次提交都立刻写磁盘。这个缓冲有默认值就够用但因为它是内存到磁盘之间的一个短暂缓冲区配置太大反而没意义太小的话在高并发大事务下会增加磁盘写入频率。Query Cache就不一样了。它在MySQL 5.7及更早版本里是个“看着很美”的功能——把SELECT语句和结果集直接缓存在内存里完全相同的SQL再来查就直接返回结果。但从实际运维来看它的失效机制太粗暴了只要涉及的表发生任何数据变更相关缓存全部失效在高并发写入场景下维护缓存和清理失效的开销甚至比查询本身的代价还大。所以MySQL 8.0直接把这个功能移除了。这个历史包袱如果你能避开就别再往里跳了。注意如果你维护的是老项目用的还是MySQL 5.7建议确认下query_cache_type参数状态。很多年久失修的服务器这个参数还是ON白白浪费内存不说还会拖慢写入性能。我自己处理过好几台这样的机器关了Query Cache之后写入性能反而涨了一截。2. InnoDB Buffer Pool调优缓存策略的地基2.1 Buffer Pool到底缓存了什么InnoDB的Buffer Pool不是简单的一个大数组它内部有多种链表和数据结构的组合。它缓存的最核心内容就是数据页和索引页。InnoDB存储数据时并不是一条一条记录往磁盘上写而是按照16KB一个页的粒度来管理的。当你查询一行数据时InnoDB会把包含这行数据的整个页从磁盘读入Buffer Pool后续再查这个页里的其他数据就直接命中内存了。除了页数据Buffer Pool里还放着插入缓冲Insert Buffer/Change Buffer、自适应哈希索引、锁信息等元数据。Change Buffer尤其有意思——当你要修改的二级索引页不在Buffer Pool里时InnoDB不会立刻去磁盘读这个页而是把修改记录在Change Buffer里等以后这个页被读入时再合并。这种延迟合并的策略极大地减少了随机IO但也意味着如果空闲时刷脏不及时Change Buffer太大会拖慢实例恢复速度。Buffer Pool内部通过LRU最近最少使用链表来管理页的淘汰。不过InnoDB的LRU不是教科书式的那种简单链表而是把链表分成了Young区和Old区。新读入的页先放到Old区头部只有再次被访问才会提升到Young区。这种设计是为了防止全表扫描或者大查询把真正热的数据全部挤出去——很多人在调优时容易忽略这个细节但它对缓存的稳定性非常关键理解了它你也就明白了为什么偶尔跑一个大的报表查询不会把线上热数据全冲掉。2.2 容量怎么定从2GB到128GB的配置思路Buffer Pool的容量设置是我每次帮人调参时第一个问的。很多服务器实际内存很大但innodb_buffer_pool_size还停在默认的128MB或者随便设的1GB、2GB这基本等于把法拉利当拖拉机开。怎么定这个值核心原则是给操作系统和其他进程留足余量的前提下尽可能把热数据装进内存。常用的经验值是物理内存的50%到70%。比如一台16GB内存的数据库专用服务器Buffer Pool设到8GB到10GB是比较合理的32GB内存可以设到20GB左右再往上走单实例到128GB内存的机器我会建议先确认清楚数据量和实际工作负载再决定是单实例占满还是分多实例部署。光看经验值还不够更可靠的做法是结合命中率微调。计算命中率的指标来自SHOW GLOBAL STATUSSHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;Innodb_buffer_pool_read_requests从Buffer Pool中读取页的请求次数Innodb_buffer_pool_reads从磁盘读取页的次数命中率可以用这个公式算(read_requests - reads) / read_requests * 100%。我一般要求线上实例的Buffer Pool命中率长期维持在99%以上如果低于95%基本说明Buffer Pool太小或者数据访问过于分散需要扩容或者优化数据访问模式。注意一次性采样会受启动时间影响所以我会连续采样几天的值再判断趋势。推荐落到配置文件里的关键参数组合如下[mysqld] # 核心缓冲池大小通常是物理内存的50%-70% innodb_buffer_pool_size 8G # 缓冲池实例数常用配置为8最大可到64 innodb_buffer_pool_instances 8 # 关闭/开启时是否保存/加载缓冲页减少重启后的预热时间 innodb_buffer_pool_dump_at_shutdown ON innodb_buffer_pool_load_at_startup ON # 刷脏控制 innodb_io_capacity 600 innodb_io_capacity_max 2000 innodb_max_dirty_pages_pct 75这里的innodb_buffer_pool_instances很多人不理解其实它是把Buffer Pool这个大池子按内存地址划分成多个小池子每个池子有独立的锁。当并发非常高、访问也不同集中时多实例能减少锁竞争。经验法则是Buffer Pool大小超过1GB时实例数按1GB一个实例来切比较合适比如8GB设8个实例。超过64个实例也没必要反而浪费内存管理开销。容量扩大会有个很现实的问题就是MySQL启动时准备内存会变慢同时重启后需要重新缓存热数据。8.0里加载Buffer Pool字典信息比以前快了不少但仍然需要时间。所以千万别在业务高峰期随手改这个参数重启否则接下来一段时间磁盘IO会明显上升等缓存“加热”完成才恢复。2.3 容易被忽略的预热、多实例与刷脏细节预热这个点我在生产环境里吃过亏。有一次接手一个项目服务器配置不低内存也加了Buffer Pool也调大了但每天凌晨定时任务一跑完数据库就开始卡顿。排查下来发现倒不是定时任务的SQL有多烂而是服务器只要重启过Buffer Pool就是空的所有热数据都要重新从磁盘加载一遍。这个“冷启动”阶段持续几十分钟到一两个小时期间任何请求都可能在磁盘上卡一下。解决办法就是用innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup这对参数。关闭MySQL时它会把Buffer Pool中页的引用信息记录到磁盘文件里启动时再根据这些信息把这些页加载回内存。注意它加载的只是页的“名单”真正把数据读入内存还是需要磁盘IO的所以这个过程不会瞬间完成但已经能够让最热的数据优先回归比全部冷启动好得多。刷脏是另一个值得盯的点。Buffer Pool里的页更新后就成了脏页InnoDB需要在后台把这些脏页写回磁盘。如果脏页积累太多前台需要查询Buffer Pool时发现没有空闲页就得强制触发刷脏造成瞬间的IO毛刺。innodb_io_capacity和innodb_max_dirty_pages_pct就是控制这个节奏的关键。我一般把innodb_io_capacity设为磁盘能力的80%左右。比如线上SSD能支撑大概800 IOPS就设600如果是高性能NVMe可以设1500到2000。innodb_max_dirty_pages_pct保持默认的75就好也不建议调太高否则一旦触发强制刷脏延迟会很难看。要实时看脏页情况和刷脏线程状态可以用这个命令SHOW ENGINE INNODB STATUS\G然后把注意力放到BUFFER POOL AND MEMORY段看Modified db pages这一项。如果这个数字会话期间长期居高不下说明刷脏能力跟不上写入速度了要么调大innodb_io_capacity要么检查有没有大事务或者大量行更新在执行。3. 从查询缓存到“不依赖MySQL缓存”缓存思路的转变3.1 为什么MySQL 8.0直接删掉了Query CacheQuery Cache在早期MySQL版本中曾经被当成宝贝功能同样的SELECT语句第一次执行后把结果集存起来第二次来查时直接返回缓存结果连SQL解析和执行计划都省了。听着特别美官方也确实默认开启过。但实际在高并发生产环境里这个功能几乎是帮倒忙的。问题出在缓存的失效粒度上。Query Cache是整表级失效的——只要某张表发生任何一次INSERT、UPDATE、DELETE操作跟这张表相关的所有查询缓存都会被清空。在写入频繁的业务里缓存基本上就是刚建好就被清掉维护这个缓存本身还需要全局锁保护反而会造成所有查询都要去抢这把锁性能直接崩掉。这就是为什么很多生产系统在关闭Query Cache后查询和写入性能反而同时提升。所以MySQL 8.0把Query Cache整个功能模块从代码里删干净了不是默认关闭是彻底不存在。如果你是8.0用户根本不用考虑这一层缓存把精力放在Buffer Pool和执行计划优化上就行。如果是老版本升级或者还在维护老架构我建议从MySQL 5.7开始就直接把query_cache_typeOFF并把query_cache_size0别再给它分配内存。3.2 新思路让MySQL尽量不“重复劳动”既然MySQL内部不那么依赖查询缓存了那提升查询性能靠什么其实归根结底是两条路一是让数据尽量留在内存中也就是前面说的Buffer Pool调优二是让单条SQL的CPU和IO成本降下来典型手段是指定合理索引、维护准确的统计信息、优化执行计划。这里重点说一下统计信息。MySQL的优化器决定走哪个索引、用哪种连接顺序依赖的是表上的统计信息。如果统计信息严重过期优化器可能挑了一个极差的执行计划哪怕数据都在Buffer Pool里也会因为扫描行数太多而变慢。常见的处理方法是保持innodb_stats_auto_recalc自动重算开启对于频繁变更的大表在大批量写入后手动执行ANALYZE TABLE。缓存策略到了这个层面已经不只是“内存够不够大”的问题而是“MySQL选路是否高效”的问题。另外一个容易被忽略的点是索引页的物理顺序。Buffer Pool解决了“读到内存”的速度但如果索引页本身离散度太高比如因为频繁随机插入导致页分裂那么即使从内存读取CPU的处理开销也会增加。这种情况下定期用OPTIMIZE TABLE重建表的聚簇索引和数据页排列能有效提高缓存的使用效率让同样大小的Buffer Pool装下更多有效数据。3.3 如果还在用5.7如何兼容老查询缓存现实情况是很多公司遗留项目还在用MySQL 5.7甚至5.6。这些项目往往有大量只读报表查询也不怎么频繁写入Query Cache在这种场景下确实能带来些收益。但我的建议依然是别依赖它趁早关掉。原因很直白它带来的收益天花板很低但引入的坑太多了。首先是命中率不稳定一旦有写入就清零运维很难给业务方一个明确的性能承诺。其次是内存浪费query_cache_size设得越大内存碎片和管理开销也越大8.0时代这套机制已经被证明是低效的。如果确实有“相同SQL并发很高”的场景正确做法是在应用层加缓存把结果放到Redis这类专门的缓存组件里而不是让MySQL自己去扛。如果你一时改不了代码只能先在5.7上顶着那也建议这样配置query_cache_type DEMAND并在需要缓存的SQL里显式加SQL_CACHE提示这样可以限制只有你想缓存的查询才进缓存减少无谓的失效开销。这算是老版本里的一个折衷操作但治标不治本。提示老版本升级到MySQL 8.0是个大工程不只是改个配置那么简单。要提前把带有SQL_CACHE、SQL_NO_CACHE提示的SQL全部清理掉否则升级后语法直接报错。还要测试字符集排序规则、认证插件等兼容性建议先在测试环境完整跑一遍业务链路再规划升级窗口。4. 真正的缓存策略在应用层MySQL与业务缓存的协同4.1 Cache Aside是默认选择什么时候读缓存、什么时候写库聊到缓存策略MySQL内部的Buffer Pool只是第一层。真正高并发的互联网项目几乎没有哪个是单纯靠数据库缓存扛住读流量的。因为数据库的内存再大也是有限的热点数据再多也架不住几十万QPS的打法。所以业务系统里最常见的缓存架构是在应用层和数据库之间再架一层缓存——通常是Redis。这层缓存怎么跟MySQL配合最经典的方案是Mode Cache Aside旁路缓存中文一般叫“缓存旁路”。它的逻辑很简单读请求先查缓存命中就直接返回没命中查MySQL把结果写回缓存再返回。写请求先更新MySQL然后删除对应缓存。写操作选择“删缓存”而不是“更新缓存”这一点很多新手想不明白。原因在于更新缓存需要把新数据完整地构建出来可能涉及多个字段的运算和关联查询成本比删除一个key高得多。而且多个并发写操作如果顺序错乱还可能把旧值写进缓存。删除缓存就没这么多问题——下一次读请求发现缓存没有自然会把最新数据重新加载进来。代码示例大概长这样// 读操作 public String getUserOrderInfo(String userId) { String key user:order: userId; String cached redis.get(key); if (cached ! null) { return cached; } // 缓存未命中查询数据库 String value userOrderMapper.queryByUserId(userId); // 回填缓存设置合理的过期时间 redis.setex(key, 300, value); return value; } // 写操作 public void updateOrder(Order order) { // 先更新数据库 orderMapper.update(order); // 再删除缓存下次读取时重建 redis.del(user:order: order.getUserId()); }这里面有两个细节很关键。第一缓存过期时间一定要加而且要根据业务耐受度来定一般5到30分钟比较常见。没有过期时间的缓存一旦写错就是长期的脏数据。第二缓存中的value序列化格式要考虑好JSON可读性好但是体积大二进制序列化省空间但排障不方便中小项目里JSON够用吞吐量极高的场景再考虑压缩或二进制。4.2 从双删到binlog订阅缓存一致性的演进之路Cache Aside看起来简洁但有一个并发黑洞读请求在缓存失效后、回填缓存前写请求刚好更新了数据库并删除了缓存随后读请求把旧数据回填到了缓存导致缓存里长期存着旧值。这种概率不高但一旦发生就很麻烦。业界对付这个问题最朴素的方案是“延迟双删”。也就是写完数据库后先删一次缓存过几百毫秒再删一次把可能回填的旧值二次清掉。这个方案实现简单能解决大部分并发场景但延迟时间不好确定删太早没意义删太晚又影响性能。我在实战中一般设500毫秒到1秒结合业务对一致性的容忍度来定。它不完美但性价比很高。再往上走就是通过订阅MySQL的binlog来同步更新缓存。现在比较常听到的中间件是Canal它把自己伪装成一个MySQL从库拉取主库的binlog解析出数据变更事件然后通知业务系统更新缓存或者同步到其他存储。这套方案的优点是解耦业务代码里不需要手动处理删缓存的逻辑数据变更以事件流的方式驱动缓存更新适合对一致性要求更高的场景。binlog订阅方案也有代价要多维护一套中间件还要处理消息延迟和重复消费幂等。对于大多数中小项目延迟双删已经够用了。但如果项目已经足够大团队也养得起中间件binlog订阅的方向会更干净也是大型架构演进的一个必经节点。4.3 穿透、击穿、雪崩缓存失效的三种“事故现场”与对策应用层缓存做得再怎么花哨都绕不开三个经典问题几乎每次聊缓存面试都会问到线上出问题也大多是这三兄弟在作怪。缓存穿透是指查询一个根本不存在的数据缓存里没有数据库里也没有每次请求都会打到数据库。如果有人恶意构造一堆不存在的ID数据库压力瞬间就会上去。解决手段最常用的是布隆过滤器把所有可能存在的主键都提前加载到布隆过滤器里请求来了先判断ID是否可能存在于数据库如果过滤器说没有直接返回空。另一个简单有效的办法是缓存空值把不存在的查询也缓存一个短暂的key比如60秒可以挡住大量重复无效查询。缓存击穿是指某个热点key突然过期此时大量并发请求同时打到数据库。比如某个爆款商品的秒杀详情页缓存里本来有过期的那一瞬间几千个请求全部涌向MySQL。防御方案有两种互斥锁和逻辑过期。互斥锁的做法是当缓存没有时先获取一把分布式锁只让一个线程去查库并重建缓存其他线程等待锁释放后重新读缓存。逻辑过期是另一种思路value里存一个逻辑过期时间读的时候发现逻辑过期不直接删key而是先返回旧数据同时异步去刷新缓存。后者对系统可用性更友好适合读多写少的场景。缓存雪崩则是大量key在同一时间段集体过期导致请求全部落到数据库或者缓存节点直接宕机数据库被打垮。应对方式首先是把过期时间离散化——在固定过期时间的基础上加一个随机偏移量比如300秒加0到60秒随机值避免同一时刻大批key到期。其次如果是Redis集群节点挂了要从架构上做高可用保障比如哨兵或Cluster模式并在应用层做好熔断降级数据库端也建议加连接池和限流保护不要裸奔。这三个问题的本质是不能把缓存层当成永远不会出问题的黑盒。缓存设计里要预留“缓存挂掉怎么办”的预案这才是架构上的成熟。5. 实战中的度量与避坑监控缓存健康度5.1 命中率这个指标该怎么看很多人一看缓存命中率99%就觉得万事大吉但我必须泼一盆冷水命中率高不代表缓存策略是健康的关键要看命中率和业务请求量的关系。比如一个冷门接口一天只有1000次请求其中990次命中缓存命中率是99%这个数据没有任何参考价值。更要注意的是命中率单一指标的陷阱如果命中率在95%以上但用户响应时间依然很慢那瓶颈多半不在缓存上而在应用层序列化、网络延迟或者数据库这边有慢SQL在拖后腿。我习惯把缓存多个指标放在一起看请求总量、命中率、回源量落到数据库的请求数、平均响应时间、以及Redis的used_memory和evicted_keys。evicted_keys尤其重要它代表内存不够时被LRU淘汰的key数量。如果这个值快速增长说明Redis可用内存不足热数据被持续淘汰此时命中率再高也只是表面繁荣很快会崩。正确的做法是根据业务增长曲线提前扩容内存或者把大key拆分成多个小key分散存储。数据库这边的监控同样要做好。SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read%要建个定时任务定期记录方便出问题的时候回溯趋势。很多企业用的监控平台如PrometheusGrafana也有现成的MySQL Exporter可以采集这些指标提前配好比你半夜被电话叫起来查一条条SQL强得多。5.2 大事务、慢SQL与缓存刷新的联动排查缓存问题往往不是孤立出现的。我处理过一个比较典型的故障现象是某个接口平时很快偶尔突然卡顿几秒。第一反应是缓存命中率出问题了但查下来Redis一切正常命中率也稳定。后来看数据库的慢查询日志发现有几条大事务更新了同一张表导致该表上的行锁排队而接口里的查询SQL因为走不到合适的索引必须全表扫描这几个因素叠加就把响应时间拉上去了。这个案例给我的教训是缓存只是数据库的“门卫”它挡不住所有问题。当应用层缓存命中的时候请求可以很快返回一旦碰上未命中需要回源数据库如果数据库本身结构或者执行计划有问题回源的那一下就会特别痛。所以在做缓存策略的同时必须同步做好数据库侧的索引优化、慢SQL治理和事务拆分。如果你遇到类似“偶发变慢”的问题可以按这个顺序排查确认缓存命中率和Redis侧是否有慢命令或大key。打开MySQL慢查询日志找到对应时间段的慢SQL。用EXPLAIN看慢SQL的执行计划确认是否走错索引或者扫描行数异常。检查数据库当时的锁等待情况SHOW STATUS LIKE innodb_row_lock%可以快速判断。如果是大事务重点查应用代码里是否存在单次请求内做了太多更新操作必要时拆成多个小事务。5.3 一套自己常用的缓存检查命令与脚本最后把我平时排查缓存问题时必用的一套命令和SQL放出来基本是”上手即用“的。这里不完全覆盖所有场景但对于快速定位80%的问题是足够的。查看MySQL Buffer Pool整体情况SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_pages_free; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_pages_total; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_pages_dirty;算命中率的公式我已经在前面写过用的时候拿两次采样的差值来计算避免从服务器启动以来的累计值误导判断。查看当前Buffer Pool配置SHOW VARIABLES LIKE innodb_buffer_pool_size; SHOW VARIABLES LIKE innodb_buffer_pool_instances; SHOW VARIABLES LIKE innodb_io_capacity; SHOW VARIABLES LIKE innodb_max_dirty_pages_pct;查看内存分配和重做日志redo log相关情况SHOW ENGINE INNODB STATUS\G在这个输出的BUFFER POOL AND MEMORY部分你会发现Free buffers、Database pages、Modified db pages等指标。Modified db pages太高就是前面提到的刷脏压力大的信号。Redis侧需要留意几个INFO项redis-cli info memory redis-cli info stats重点看used_memory、maxmemory、evicted_keys、keyspace_hits和keyspace_misses。Redis的命中率计算是keyspace_hits / (keyspace_hits keyspace_misses)这个值连同比和环比一起看如果短时间内明显下滑要么是过期时间太激进要么是访问模式变化要么就是内存满了在疯狂淘汰。再说个我自己保持的习惯每周跑一次脚本把这些关键指标存到一张统计表里每周对比一下趋势。缓存调优不是一锤子买卖它是随着业务数据量和访问模式变化而动态调整的过程。建立历史基线后哪天指标异常你能第一时间知道是“突然变化”还是“早就该处理了”。我个人的一个体会是缓存策略从来不是孤立的配置游戏而是数据库、应用、业务三个层面协同出来的结果。MySQL内部的Buffer Pool要把热数据留在内存里这是地基应用层要根据业务特征设计合适的缓存结构和失效策略这是主体而监控和预案则是保障整套系统稳稳跑下去的护栏。三者缺一不可。最后再分享一个小技巧每当你给某个缓存key设置过期时间之前先想一下“这个时间用户能接受吗数据库能扛住吗过期后有多少并发会同时打过来”把这三件事想清楚了80%的缓存事故你都已经提前避开了。