mysql 8.0 中 query_cache_type 已被源码级删除，无法开启；必须删除所有 querycache* 配置项，改用应用层缓存（如 redis）和调优 innodb_buffer_pool_size。
query_cache_type 在 MySQL 8.0 中已不存在，不是配置不生效，而是源码级删除。你无法通过任何参数“开启”查询缓存——它彻底没了。
直接删掉所有 query_cache_* 配置项
如果你是从 5.7 升级上来的，my.cnf 里还留着 query_cache_type=1、query_cache_size=64M 这类配置，MySQL 8.0 启动时会报 Unknown system variable 'query_cache_type' 警告，且忽略它们。继续保留只会干扰配置可读性，也容易误导新同学以为“还能开”。
- 检查配置文件，删掉所有以
query_cache_开头的行 - 重启 mysqld 后用
SHOW VARIABLES LIKE 'query%';确认无返回结果 - 别试图用
SET GLOBAL动态设置——变量根本不存在，语法错误
高频重复读取该交给 Redis，而不是幻想“数据库缓存”
原来 query_cache 处理的典型场景（如字典表、配置项、省市区列表），现在必须由应用层显式接管。Redis 是最直接、最可控的替代，但要注意三点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 缓存键要带业务语义，比如
config:feature_flags，而不是简单哈希 SQL 字符串——后者在应用层难以维护和失效 - TTL 设置要有余量：静态数据设
3600（1 小时）比永不过期更安全；若依赖 DB 变更事件主动失效，必须确保写操作和 DEL 操作在同一事务边界外原子执行（例如用 binlog 监听或应用层双写） - 避免缓存空结果（
NULL或空数组）却不设 TTL，否则一次查询失败可能长期掩盖真实问题
InnoDB 缓冲池不是“查询缓存”，但能间接提升重复查询速度
innodb_buffer_pool_size 是你此刻最该调优的内存参数。它不缓存“查询结果”，而是缓存数据页和索引页——只要热点数据常驻内存，相同 WHERE 条件的 SELECT 就能绕过磁盘 I/O，性能提升非常实在。
- 建议设为物理内存的 60%–80%，例如 32GB 机器可设
innodb_buffer_pool_size = 24G - 启用
innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup，避免重启后冷启动抖动 - 监控
Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads，比值大于 99% 才算健康；低于 95% 就说明频繁刷盘，得扩容或优化索引
别碰 ProxySQL 的 query cache 功能
ProxySQL 确实支持基于 SQL 文本的缓存，但它复刻了老版 MySQL 查询缓存的所有缺陷：表级失效、大小写敏感、无法处理参数化查询。在 OLTP 场景下，它极易成为新的单点瓶颈。
- 它的缓存命中率在真实业务中通常低于 10%，反而增加代理层延迟
- 一旦上游 DB 发生 DDL 或主从切换，缓存一致性极难保障
- 除非你有完全静态、只读、且 SQL 绝对规范的报表库，否则不要启用
mysql-query_rules.cache_ttl
真正麻烦的不是“怎么缓存”，而是“缓存失效时机是否和业务一致”。比如用户资料页展示“最后登录时间”，缓存 5 分钟可以接受；但支付订单状态变更，缓存哪怕 1 秒都可能引发资损。这类判断没法交给数据库自动做，只能靠你在代码里写清楚：什么查缓存、什么直连、什么先删再写。
