MySQL里头缓存到底咋管，思路和方法大概聊聊

MySQL的缓存这个话题，其实有点“年代感”，因为最著名、也最常被讨论的那个“查询缓存”功能，在MySQL 5.7版本还存在着，但到了8.0版本就被彻底移除了，所以咱们得分开聊，一个是已经成为历史的“查询缓存”，另一个是现在依然非常重要、但概念更宽泛的“缓存管理思路”。

第一部分：曾经的王者——查询缓存

这个功能的想法非常简单直接，用大白话说就是：MySQL想把之前执行过的查询语句和查询结果，像存备忘录一样存起来，下次你再发来一模一样的查询语句，它就不用吭哧吭哧地去硬盘里翻数据了，直接从这个“备忘录”里把结果拿出来还给你,速度飞快。

听起来很美是吧？但为啥后来又被抛弃了呢？根本原因就一个字：“锁”。

这个查询缓存有个挺要命的设计：它对整个缓存区域有一把“大锁”，也就是说，任何时候，只要有一个人在查询缓存里读结果，其他所有人都得等着，不能往里写也不能读，这还不要紧，更要命的是，任何一张数据表，只要发生了哪怕一丁点儿变化（比如你更新了其中一行数据），那么所有和这张表有一丁点儿关系的查询结果，都会从缓存里被整个清理掉！

你可以想象一下这个场景：你的网站首页很复杂，需要执行一个复杂的SQL语句才能把数据拼出来，这个语句第一次执行花了2秒钟，然后结果被缓存了，之后99个用户来访问，因为走了缓存，只花了0.01秒就打开了首页，体验极好，但这时候，有个后台管理员，只是修改了某个用户的昵称（更新了users表里的一行数据），砰的一声！整个缓存里所有和users表相关的查询结果，包括你那个复杂的首页查询，全被清空了，第100个用户再来访问首页,又得等上那漫长的2秒钟。

在读写混合比较频繁的应用里，这种“缓存命中率”会非常低，缓存刚费劲存好，马上就被清掉了，维护这个缓存本身（比如要判断哪些表相关、要加锁解锁）也需要消耗不少CPU资源，最后就变成了“得不偿失”，缓存不但没帮上忙，反而成了拖累，所以MySQL开发团队一狠心，在8.0版本就把它给删了，这个思路的失败，也给我们提了个醒：过于精细、关联性太强的缓存，维护成本可能高到无法承受。

第二部分：现在的缓存管理思路——把钱花在刀刃上

既然那个“小聪明”的查询缓存不好用，那MySQL现在靠什么提速呢？答案是更根本、更“笨”但更有效的方法：主要靠缓冲池，说白了，就是尽量让数据待在内存里别老去读硬盘。

硬盘（尤其是机械硬盘）是电脑里最慢的部件之一，而内存的速度快得多，MySQL的核心——InnoDB引擎，有一个非常重要的东西叫缓冲池，你可以把它想象成MySQL在内存里申请的一大块“高级工作台”。

这个工作台主要干两件事：

1. 缓存数据页：数据在硬盘上是分成一页一页存放的（比如每页16KB），当你查询数据时，InnoDB会先把需要用到的那些“数据页”从硬盘搬到这个“工作台”（缓冲池）里来，然后再从工作台里把你要的数据找出来，下次如果你还要读这个页上的数据，如果它还在工作台上，就直接用,省去了慢吞吞的硬盘读取。
2. 缓存索引页：索引（比如你给表的主键、用户名建的索引）也是一页一页的，同样，常用的索引页也会被放在这个工作台上,加快查找速度。

管理MySQL缓存的核心思路，很大程度上就变成了：如何管理和优化这个“缓冲池”（InnoDB Buffer Pool）。

具体怎么做呢？大概有这几个方向：

1. 给缓冲池足够大的内存：这是最直接、最有效的一招，如果你的数据库有10GB的数据，你给缓冲池分配了8GB的内存，那么绝大部分常用数据和索引都能被装进去，速度自然会飞快，这个大小通过参数innodb_buffer_pool_size来设置，通常建议在服务器内存允许的情况下，尽可能设大一点，比如占服务器总内存的50%-70%（要留给操作系统和其他程序一些）。

   

2. 理解缓冲池的置换策略：内存是有限的，不可能放下所有数据，当工作台摆满了，又有新数据页要放进来时，就得把一些旧的、不常用的页请出去，这个策略MySQL已经帮你优化得很好了（类似LRU，最近最少使用算法），你一般不用太操心，但你需要关注的是缓冲池命中率这个指标（可以用SHOW ENGINE INNODB STATUS命令查看），如果命中率很高（比如99%以上），说明你的缓冲池大小是合适的，大部分请求都命中了内存，如果很低,那可能就需要考虑加大缓冲池了。

3. 利用多实例减少锁争用：在高并发的环境下，缓冲池本身也可能成为瓶颈，因为很多线程要同时访问它，MySQL允许你把一个大的缓冲池分割成多个小的区域（通过innodb_buffer_pool_instances参数），这样可以减少线程之间的等待,提高并发性能。

4. 其他层面的缓存：除了缓冲池这个大头,MySQL还有其他一些小的缓存机制。

   • 表缓存：缓存的是表的定义信息（结构），这样不用每次查表都去解析结构,一般问题不大。
   • 日志缓存：比如redo log buffer，先把要写的日志放在内存里，然后批量刷到硬盘,也是为了提升写性能。

总结一下现在的思路：

别再怀念那个已经被抛弃的查询缓存了，现在管好MySQL缓存，关键在于管好缓冲池，思路很朴实：尽可能把“钱”（内存）投资在缓冲池上，让它足够大，能把热点数据都装下，让硬盘这个慢家伙尽量少干活。 监控缓冲池的命中率，确保你的投资是有效的，对于极致的性能要求，可以通过分片、读写分离等架构层面的设计来分担单机缓存压力,但那已经是另一个维度的话题了。

（主要参考来源：MySQL官方文档关于InnoDB缓冲池的说明，以及《高性能MySQL》一书中关于缓存设计的讨论）