17370845950

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) = 2025）→ 索引失效，退化为全表扫描

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 上，既不可靠，又模糊了各层职责。