MySQL 8.0 彻底删除 query_cache_type 等所有查询缓存变量，配置即报错启动失败；必须手动清除 my.cnf 中所有 query_cache_ 开头的行，并改用 InnoDB 缓冲池优化、应用层缓存等替代方案。
MySQL 8.0 里根本不存在 query_cache_type 这个变量——不是“关了”，是源码里删干净了；配置文件里留着它，MySQL 直接启动失败。
my.cnf 里还留着 query_cache_* 就起不来服务
从 MySQL 8.0.3 起，所有 query_cache_type、query_cache_size、query_cache_limit 等变量全被物理删除。mysqld 启动时解析配置，遇到不认识的变量就报错退出，典型错误是：Unknown system variable 'query_cache_type' 或 Unknown variable 'query_cache_size'。
- 必须手动删除 my.cnf（或 my.ini）中所有以
query_cache_开头的行，包括注释掉的（如# query_cache_type = 1）也要删，某些解析器会误判 - Percona Server 8.x、MariaDB 10.6+ 同样不识别，别指望兼容
- 云数据库（RDS）、Docker 镜像若复用旧参数组或配置模板，同样卡在这一步，得逐项检查并清理
- 验证方式：启动前执行
mysqld --validate-config，比靠日志翻找更直接
SELECT SQL_CACHE 在 MySQL 8.0 中直接报语法错误
这不是提示被忽略，而是 SQL 解析器压根不再支持该关键字。执行类似语句会立刻失败：
SELECT SQL_CACHE * FROM users WHERE id = 1;
报错：ERROR 1286 (42000): Unknown table engine 'QUERY CACHE'。连语法树构建阶段都过不去，没有 fallback 行为。
-
SQL_NO_CACHE同样无效，但不会报错（只是被静默丢弃） - 试图用 init_connect + 自定义函数拦截 SQL 并模拟缓存？不可靠：无法感知隐式 DDL（如
ALTER TABLE ... RENAME COLUMN），也无法处理 MVCC 快照一致性 - 社区没有安全、可靠的 Query Cache 插件——官方不提供，第三方实现绕不过事务可见性与主从延迟问题
真正该调的不是查询缓存，而是 innodb_buffer_pool_size
InnoDB Buffer Pool 是现代 MySQL 最关键的缓存层，它缓存的是数据页而非 SQL 结果，无全局锁、无表级失效风暴、命中后直接内存读，且与写操作天然协同。
- 中低端服务器建议设为物理内存的 50%–75%，例如 2GB 总内存可设
innodb_buffer_pool_size = 1G（注意单位！写成1024M或1G，不能只写1024） - 验证是否生效：
SHOW STATUS LIKE 'Innodb_buffer_pool_read%'，计算Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads，比值 > 99% 才算健康 - 避免和 Query Cache 当年一样的陷阱：不要迷信“缓存结果”，要优先保证热数据页常驻内存——索引设计、覆盖索引、慢查优化比任何结果缓存都实在
应用层缓存比 SQL 级缓存更可控
Query Cache 失败的本质，是在 SQL 解析层强行做结果级缓存，却扛不住数据一致性压力。替代方案的关键不是“换一个缓存”，而是换位置、换粒度、换控制权。
- 高频只读小数据（如配置项、状态码）：用
apcu_store()/apcu_fetch()（PHP）或 Redis 的SETEX config:app:features 3600 {...} - 维度表（城市、分类）：加
WHERE updated_at 条件，缓存 1 小时，更新时主动 <code>DELkey - 聚合统计（日订单数）：改用定时任务预计算，结果存
cache:daily_order_count，避免实时 COUNT 压垮 DB - 绝不缓
SELECT * FROM users WHERE id = ?这类通用查询——除非你明确拼出user:123这样的 key，并在 UPDATE 后主动失效
最易被忽略的一点：即使你在旧版 MySQL 上配好了 query_cache_size，只要 SQL 里带 NOW()、用户变量、子查询或临时表，结果照样不进缓存——而这些在 ORM 和现代业务逻辑里太常见了。与其花时间调参，不如把精力放在 Buffer Pool 容量、索引有效性、以及哪条 SQL 真正值得缓到应用层。
