社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
MySQL查询缓存保存查询返回的完整结果。当查询命中缓存，MySQL会立刻返回结果，跳过了解析，优化和执行阶段。
查询缓存执行过程：
1.通过一个大小写不敏感的检查看看SQL语句是不是以SEL开头。
2.若是以SEL开头则获取缓存数据，若是命中则直接返回结果。
3.若没有命中，则通过SQL语句查询数据。
4.返回查询结果给客户端。同时存入查询缓存，但不是所有的查询结果都会存入查询缓存，详细见下面。
缓存未命中可能的情况：
1.由于查询语句中包含不确定的函数，或者查询结果太大，超过query_cache_limit的值，查询结果无法缓存。
2.MySQL从未处理过这个查询，查询结果没有缓存过。
3.之前缓存了查询结果，但是由于查询缓存内存不足，MySQL将某些缓存逐出，导致未命中。
4.缓存失效操作太多。数据修改，内存不足，缓存碎片都会导致缓存失效。
5.查询缓存还没有完成预热，MySQL还没有机会将查询结果都缓存起来。
不会缓存结果的情况：
1.当查询语句中有一些不确定的数据时，则不会被缓存。如包含函数NOW()，CURRENT_DATE()等类似的函数，或者用户自定义的函数，存储函数，用户变量等都不会被缓存。
2.当查询的结果大于query_cache_limit设置的值时，结果不会被缓存。
3.对于InnoDB引擎来说，当一个语句在事务中修改了某个表，那么在这个事务提交之前，所有与这个表相关的查询都无法被缓存。因此长时间执行事务，会大大降低缓存命中率。
查询缓存带来的额外消耗：
1.在查询之前必须先检查是否命中缓存。
2.如果这个查询可以被缓存，那么执行完成后，MySQL发现查询缓存中没有这个查询，则会将结果存入查询缓存，这会带来额外的系统消耗。
3.写入或更新数据时，MySQL必须将对应表的所有缓存都设置失效。如果查询缓存很大或者碎片很多时，这个操作可能带来很大的系统消耗。
查询缓存内存使用：
在查询开始返回结果的时候就分配空间，而此时无法预知查询结果有多大，所以MySQL无法为每一个查询结果精确的分配缓存空间。
当需要将查询结果缓存的时候，MySQL先申请一个数据块存储结果，不论结果大小，都会至少申请一个query_cache_min_res_unit的空间，然后将结果写入数据块，若申请的数据块不足以存储结果，那么再申请一个数据块，直到全部存储完成。
当查询完成后，如果申请的内存空间还有剩余，MySQL会将其释放，并放入空闲内存部分，这样是不会产生碎片。
通过下面的步骤来验证这个问题：
设置的分配内存块的最小单位为4kb。
首先执行 show status like 'qcache%'; 查看缓存使用情况。
此时可以看到Qcache_free_blocks的值为1，说明有一个空闲块。
现在执行一条查询语句 select * from people where id =10001，数据远远小于4kb，且之前没有被缓存。
然后再执行 show status like 'qcache%'; 查看缓存使用情况。
而此时还是只有一个空闲块，说明在没有并发查询的情况下，MySQL会将存储查询结果后产生的剩余空间释放，不会产生碎片。
碎片如何产生：
假设查询的结果非常小，服务器在并发的向两个链接返回结果，这是在向A和B两个内存块写入数据，返回完结果后回收剩余的空间时，A剩余的空间小于query_cache_min_res_unit设置的值，这样就不能再次被查询缓存使用，从而产生了碎片，B剩余的空间则会释放，并入空闲内存部分。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
