共计 2481 个字符，预计需要花费 7 分钟才能阅读完成。
《MySQL 面试小抄》查问缓存机制终面
我是肥哥，一名不业余的面试官！
我是囧囧，一名踊跃找工作的小菜鸟！
囧囧示意：小白面试最怕的就是面试官问的知识点太抽象，本人无奈疾速定位到关键问题点！！！
本期次要面试考点
面试官考点之简述一下什么是查问缓存机制？面试官考点之查问如何命中缓存？面试官考点之什么场景下 SQL 和后果集不会被缓存？面试官考点之什么场景下会导致 MySQL 缓存生效？面试官考点之查问缓存是如何进行内存治理的？面试官考点之 MySQL 是一次性调配所有的内存空间吗？面试官考点之缓存中的内存碎片无奈防止，那么有什么方法优化吗？面试官考点之 MySQL4.0 提出了查问缓存，它设计进去是为了减速哪些查问场景？面试官考点之 MySQL5.6 中默认禁用，8.0 当前齐全移除，造成这个扭转的起因是什么？面试官考点之生产环境要不要开启 MySQL 缓存？
面试官考点之简述一下什么是查问缓存机制？
MySQL 服务器高负载状况下，咱们须要采取一种措施给服务器加重压力，一个简单的查问是十分耗费性能的，
其中磁盘 IO 又占据次要资源，缓存是对系统性能优化的一种重要伎俩。
查问缓存机制设计是为了从根本上缩小磁盘 IO 次数，MySQL 开启缓存后，将 SQL 和后果集以键值对 KV 的模式存储在内存中。
当雷同的 SQL 再次进入，MySQL 辨认是雷同查问喉，会间接返回缓存在内存中的后果集。
防止再次进行一系列简单的解析优化和磁盘 IO 过程。
面试官考点之查问如何命中缓存？
select id from user;
select id FROM user;下面语句能命中缓存吗？
MySQL 缓存命中机制有严格刻薄的要求，在判断命中前，MySQL 不会对 SQL 做任何的解析解决。
SQL 上的任何字符的不同，如大小写、空格、正文等都会导致缓存不命中所以下面查问时无奈命中缓存的。
面试官考点之什么场景下 SQL 和后果集不会被缓存？
或者说缓存规定是什么？
第一种状况：查问语句中蕴含不确定数据
例如查问语句中蕴含不确定函数：NOW()、CURRENT_DATE()等。因为每次执行这类带了不确定数据的查问所返回后果可能是不同的。第二种状况：超过了 query_cache_limit 预设阈值
超出了缓存内存能接受的范畴，将放弃缓存！面试官考点之什么场景下会导致 MySQL 缓存生效？
任何对于 表构造或者表数据的更新操作，肯定会造成查问缓存中的数据生效，同时查问缓存值的相干条目也会被清空。
MySQL 断定有更新操作，就会设置所有的查问缓存生效。
面试官考点之查问缓存是如何进行内存治理的？
MySQL 服务启动，缓存机制会在内存中开拓一块内存，
其中会 划分出一块区域 专用来治理保护缓存数据的 元数据。
例如空间内存、数据表和查问后果的映射，SQL 和查问后果的映射
MySQL 缓存机制将残余的闲暇空间分为一个个小 数据块，用来存储缓存后果。
每个小块中存储本身的类型，大小和查问后果数据，还有指向前后内存块的指针面试官考点之 MySQL 是一次性调配所有的内存空间吗？
MySQL 因为无奈预知查问后果大小，所以无奈为每个查问后果准确调配大小恰好匹配的缓存空间。
MySQL 缓存机制采纳的是边查边存，动静的去申请缓存内存。
一条 SQL 查问缓存分配内存过程是怎么样的？
当有查问后果须要缓存的时候，MySQL 缓存机制会在 SQL 查问开始（还未失去后果）时就去申请一块内存空间（小数据块），在一直查问中，如果发现不够则持续申请 ， 如果存储完时有空余则开释多余的内存空间。
如果余下的须要回收的空间很小，小于 query_cache_min_res_unit，不能再次被应用，可能会造成内存碎片，影响查问性能。
面试官考点之缓存中的内存碎片无奈防止，那么有什么方法优化吗？
没有什么方法可能完全避免内存碎片，然而抉择适合的
query_cache_min_res_unit
能够缩小由碎片导致的内存空间节约。
值太小，则节约的空间更少，然而会导致频繁的内存块申请操作如果设置得太大，那么碎片会很多调整适合的值其实是在均衡内存节约和 CPU 耗费
那么我如何确定这个均衡值？
能够通过内存理论耗费，计算单个查问的均匀缓存大小
（query_cache_size - Qcache_free_memory）/ Qcache_queries_in_cahce通过查看闲置内存块数量（Qcahce_free_blocks）来察看碎片。
如果产生的碎片过多，通过什么办法能够整顿碎片？
通过 FLUSH_QUERY_CAHCE 清理碎片
这个命令将所有的查问缓存从新排序，并将所有的闲暇空间都聚焦到查问缓存的一块区域上。面试官考点之 MySQL4.0 提出了查问缓存，它设计进去是为了减速哪些查问场景？
1、并发性和查问 QPS 不高
2、被拜访的底层数据实质上是动态或半动态的
3、查问密集型利用，更新频率非常低而只读查问频率十分高的场景
面试官考点之 MySQL5.6 中默认禁用，8.0 当前齐全移除，造成这个扭转的起因是什么？
现实状况下，上述查问场景非常适合应用查问缓存，然而 理论的业务零碎都是有 CRUD 操作 的。
在 MySQL 里 QC 是由一个全局锁在管制，每次更新 QC 的内存块都须要进行锁定，数据更新频繁，就会一直的生效缓存操作，同时缓存生效会造成大量的查问 缓存碎片化，还会导致服务器的负载升高，影响数据库的稳定性。
所以 MySQL 官网通过抉择，果决移除了查问缓存模块。
面试官考点之生产环境要不要开启 MySQL 缓存？
倡议不开启
依据 MySQL 官网的测试，如果对一个表执行简略的查问，设置每次查问都不一样，关上 QC 后，性能反而降落了 13% 左右当然理论业务中，不会都是这种不同的申请，因而理论影响应该比这个小一些。
MySQL 查问缓存的目标是为了晋升查问性能，但它自身也是有性能开销的。须要在适合的 业务场景下（读写压力模型）应用
不适合的业务场景岂但不能晋升查问性能，查问缓存反而会变成 MySQL 的瓶颈。对写密集型的利用场景来说，禁用缓存反而进步性能。随缘更新，整顿不易，欢送分割小白探讨，大神巴巴请绕路！
更多精彩内容，欢送关注微信公众号：囧么肥事 (或搜寻：jiongmefeishi)