MySQL 8.0+ 已彻底移除查询缓存，query_cache_type等参数无效且会导致启动报错；应转向应用层缓存（如Redis）和合理配置innodb_buffer_pool_size。
MySQL 8.0 之后查询缓存已被移除，别再配 query_cache_type
直接说结论：如果你用的是 MySQL 8.0 或更新版本，query_cache_type、query_cache_size 这些配置项已彻底删除，设了也不生效，还会导致启动报错 Unknown system variable 'query_cache_type'。官方移除理由很明确——在多数 OLTP 场景下，查询缓存的锁竞争和失效开销远大于收益，尤其高并发写入时反而拖慢整体性能。
如果你还在文档或旧教程里看到“开启查询缓存提升性能”，请先确认 MySQL 版本：
SELECT VERSION();
5.7 及更早版本才支持；8.0+ 必须转向其他缓存策略。
替代方案：用应用层缓存 + 合理利用 InnoDB 缓冲池
真正有效的缓存不在 SQL 层，而在两处：应用代码里（如 Redis、本地缓存）和 InnoDB 的 innodb_buffer_pool_size。后者负责缓存表数据和索引页，对读密集型查询影响最大。
-
innodb_buffer_pool_size建议设为物理内存的 50%–75%，但不要超过可用内存，否则触发 swap 会雪崩 - 避免把
innodb_buffer_pool_size设成固定值后长期不调；随着数据增长，要定期看Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads比率（越接近 1 越好） - 对频繁读取的小结果集，更适合在应用层加缓存：比如用户资料、配置项、地区列表——这类数据变化少、key 明确、可主动失效
哪些查询曾受益于旧版查询缓存？现在该怎么处理？
过去能从查询缓存直取结果的，基本满足三个条件：SQL 文本完全一致、表没被修改、结果集小。典型例子：SELECT status FROM orders WHERE order_id = 12345;。这类查询现在应：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 确保
order_id有索引（最好是主键或唯一索引），让 InnoDB 缓冲池高效命中数据页 - 在应用中用 key（如
order:12345）缓存结果，TTL 设短（比如 5 分钟），配合数据库变更事件主动删缓存 - 避免用
SELECT *或带函数/变量的语句——它们无法被旧查询缓存识别，现在也难被应用缓存复用
误配查询缓存带来的典型症状
即使在 5.7 环境下，盲目开启查询缓存也可能引发问题：
- 写入变慢：每次 UPDATE/INSERT/DELETE 都要清空所有涉及该表的缓存条目，锁表时间延长
- 内存浪费：设了
query_cache_size = 256M但实际命中率低于 10%，Qcache_hits / (Qcache_hits + Qcache_inserts)过低 - 结果陈旧：缓存未及时失效，用户看到过期数据（尤其没配
query_cache_wlock_invalidate=ON时）
查命中率用：
SHOW STATUS LIKE 'Qcache%';
关键看 Qcache_hits 和 Qcache_lowmem_prunes —— 后者频繁增长说明缓存碎片严重或大小不合理。
真正需要调的不是查询缓存，是缓冲池大小、索引设计、慢查询归因，以及应用是否做了无意义的重复查询。
