mysql安装完成后配置查询缓存与性能调优

MySQL 8.0 起查询缓存已被彻底移除，query_cache_type 和 query_cache_size 配置无效，启动会报错；其废弃主因是命中率低、锁竞争高、失效逻辑复杂，反而降低高并发性能。

MySQL 8.0 以后查询缓存已被移除，query_cache_type 不再生效

直接说结论：如果你用的是 MySQL 8.0 或更新版本（包括所有 Percona Server 8.x、MariaDB 10.6+），query_cache_size 和 query_cache_type 这两个配置项已彻底删除，配置文件 里写了也无效，启动时会报 Unknown variable 'query_cache_type' 警告，甚至无法启动。

这是官方明确废弃的功能——因为查询缓存存在严重缺陷：缓存命中率低、锁竞争高、失效逻辑复杂（一张表被 UPDATE 就让全库相关缓存失效），反而在高并发场景拖慢性能。

所以别再找“如何开启 MySQL 查询缓存”的教程了，除非你还在用 MySQL 5.7 或更老版本（且确认业务场景确实适合）。

MySQL 5.7 中启用查询缓存的实操要点

仅适用于 MySQL 5.7（含 5.7.20 之前版本），且必须满足以下条件才可能有收益：

• query_cache_type = 1（ON）或 = 2（DEMAND，需 SQL 显式加 SQL_CACHE）
• query_cache_size > 1048576（至少 1MB，否则自动禁用）
• 查询必须是确定性 SELECT（不能含 NOW()、USER()、子查询含临时表等）
• 涉及的表未被其他连接执行过 INSERT/UPDATE/DELETE

常见错误配置：

• 只设 query_cache_size = 1048576，但没开 query_cache_type → 缓存不工作
• 设了 query_cache_size = 0 → 启动后 SHOW VARIABLES LIKE 'query_cache%' 全为 OFF/0
• 用 SELECT SQL_NO_CACHE …… 测试时误以为缓存失效是 bug → 实属正常行为

替代查询缓存的真实性能调优方向

现代 MySQL 性能瓶颈 极少出在“重复查相同 SQL”上，更多卡在 I/O、锁、执行计划、连接数。优先检查这些：

• 确保 innodb_buffer_pool_size 设为物理内存的 50%–75%（不是默认的 128MB）
• 关闭 innodb_flush_log_at_trx_commit = 2（若可接受秒级 数据丢失）
• 用 EXPLAIN FORMAT=JSON 查看慢查询是否走了索引；避免 SELECT * 和 隐式类型转换
• 监控 Threads_connected 和 Aborted_connects，防止连接泄漏或认证失败风暴
• 用 performance_schema 开启 events_statements_history_long 抓取 Top SQL，而非依赖缓存命中率

如果真有高频固定结果集（比如配置表、地区字典），应用层用 Redis / local cache 更可控、更高效。

验证查询缓存是否工作的命令和陷阱

在 MySQL 5.7 环境下，用以下方式验证（注意：必须用新连接、无其他写操作干扰）：

SELECT SQL_NO_CACHE COUNT(*) FROM orders; SELECT SQL_CACHE COUNT(*) FROM orders; SHOW STATUS LIKE 'Qcache%';

关键指标看：

• Qcache_hits：缓存命中次数（增长说明起效）
• Qcache_inserts：新缓存条目数（太高说明重复查询少或缓存碎片多）
• Qcache_lowmem_prunes：因内存不足被挤掉的缓存数（持续增长说明 query_cache_size 太小或缓存太碎）

容易忽略的一点：MySQL 查询缓存对大小写敏感、空格敏感、注释敏感——SELECT * FROM t 和 SELECT * FROM t; 是两条不同缓存。别用 ORM 自动生成带随机注释的 SQL 去测试缓存效果。