MySQL 8.0+ 已彻底移除 query_cache_type 和 query_cache_size，配置即报错、服务无法启动；性能瓶颈多在 I/O 与执行路径，应优先优化索引、执行计划及 SQL 重写。
MySQL 8.0 中 query_cache_type 已失效，别再配它
直接说结论：query_cache_type 和 query_cache_size 在 MySQL 8.0+ 中已被彻底移除，配置文件里写了会报错 Unknown system variable 'query_cache_type'，服务甚至无法启动。这不是“没生效”，而是代码级删除——连变量定义都没了。
常见错误现象：
- 从 5.7 升级到 8.0 后，
my.cnf里还留着query_cache_type = 1→ 启动失败 - 用
SHOW VARIABLES LIKE 'query_cache%'查不到任何结果 → 正常，不是命令错了 - 误以为“缓存没开所以 QPS 上不去” → 实际瓶颈根本不在这里
QPS 上不去？先看是不是被回表或全表扫描拖垮了
MySQL 8.0 的真实性能瓶颈，90% 以上出在 I/O 和执行路径上，而不是“重复查同一 SQL”。比如：
-
SELECT *配合WHERE status = 1，但status没索引 → 全表扫描 + 大量磁盘读 - 联合查询中
JOIN字段无索引 →type: ALL，Extra: Using join buffer - 分页写成
LIMIT 100000, 20→ 每次都扫前 10 万行
用 EXPLAIN 看执行计划比调任何缓存参数都管用。重点关注 type（至少要 range 或 ref）、key（是否用了索引）、rows（预估扫描行数）。
查询重写不是“把 SQL 改成 SELECT 1”，而是绕过低效路径
所谓“查询重写”，在生产环境里不是魔改语法取巧，而是用更少的 I/O 完成同样语义。典型手法有：
- 用覆盖索引替代
SELECT *：比如只查id和name，就把这两个字段加进联合索引，避免回表 - 延迟关联（Deferred Join）：
SELECT u.* FROM users u JOIN (SELECT id FROM users WHERE status = 1 LIMIT 100) t ON u.id = t.id，先用索引快速捞主键，再精准回查 - 把
IN (subquery)拆成两步：先查出 ID 列表（小结果集），再用WHERE id IN (...)，避免优化器误判
这些重写不依赖任何缓存机制，也不需要应用层配合，SQL 层面就能落地，效果立竿见影。
高频固定结果集，交给 Redis 或本地缓存更靠谱
如果真有那种“几乎不更新、被大量请求”的数据（比如字典表、开关配置），硬塞进数据库查，再怎么优化也是浪费连接和解析开销。
- 应用启动时加载一次进内存（如 Java 的
ConcurrentHashMap），设置 TTL 或监听 DB 变更事件刷新 - 用 Redis 缓存结果，Key 设计为
config:feature_flags这类语义化名称，避免拼 SQL 当 Key - 不要用 MySQL 自己的缓存逻辑去模拟这个场景——它没提供 TTL、没提供细粒度失效，反而更难控
真正容易被忽略的是：**QPS 提升的上限，取决于单次查询的最小 I/O 成本，而不是缓存命中率。** 把一次查询从 10ms（含 8ms 随机读）压到 1ms（纯内存索引扫描），比加一层命中率 99% 的查询缓存有用十倍。
