MySQL查询缓存已弃用，8.0彻底移除，5.7默认关闭；高写入下命中率趋零且引入锁开销；性能优化应聚焦索引（EXPLAIN看type/key/rows）、InnoDB缓冲池配置（innodb_buffer_pool_size设为内存50%–75%，命中率>99%），以及应用层可控缓存（如Redis）。
MySQL 查询缓存（Query Cache）早已被弃用，别再依赖它做性能优化
MySQL 8.0 起已彻底移除 query_cache_type 和相关配置，5.7 也默认关闭；即使旧版本开启，SELECT 结果缓存也只在表无任何变更时才命中——只要 INSERT/UPDATE/DELETE 碰过该表，整个表对应的所有缓存条目全失效。这导致高写入场景下缓存命中率趋近于零，反而因维护缓存锁带来额外开销。
索引优化不靠缓存，靠执行计划是否走 key 和 rows 是否合理
真正影响查询速度的是优化器能否利用索引快速定位数据，而不是“上次查过、这次直接返回”。判断依据是 EXPLAIN 输出中的 type（应避免 ALL）、key（是否用了索引）、rows（扫描行数是否远小于表总行数）。
-
WHERE条件字段没建索引 → 类型常为ALL，rows= 全表行数 - 复合索引顺序不匹配
WHERE条件顺序 → 可能只用上最左前缀，rows明显偏高 - 对索引字段用函数或表达式（如
WHERE YEAR(created_at) = 2024）→ 索引失效，退化为全表扫描
innodb_buffer_pool_size 才是真正的“热数据缓存”核心
InnoDB 层的缓冲池（buffer pool）缓存的是数据页和索引页，不是 SQL 结果。它直接影响磁盘 I/O 频率：设置过小会导致频繁刷页、读盘；过大可能挤占系统内存引发 swap。生产环境通常设为物理内存的 50%–75%，且必须大于单个热点表的聚簇索引大小。
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
观察命中率：
SHOW STATUS LIKE 'Innodb_buffer_pool_%';关键指标是
Innodb_buffer_pool_read_requests（逻辑读）与 Innodb_buffer_pool_reads（物理读）之比，理想值应 > 99%。
应用层若真需结果复用，得自己控制，而非指望 MySQL
数据库本身不提供安全、可控的结果级缓存机制。需要复用查询结果时，应由应用层决策：
- 对不变或低频变数据（如省份列表），用 Redis 缓存序列化结果，设置明确 TTL
- 对用户会话级结果（如个人订单列表），加
user_id前缀缓存，避免越权 - 禁止缓存带
NOW()、RAND()、用户变量等非确定性表达式的查询
索引设计和 buffer pool 配置才是数据库内核级的性能基石；把缓存逻辑堆在 MySQL 上，既不可靠，又模糊了各层职责。
