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