mysql 8.0起已移除查询缓存，此前版本无日志功能，需通过Qcache状态变量、慢查询日志及Performance Schema间接分析缓存效果，并建议用应用层缓存替代。
MySQL 本身并不直接提供“查询缓存日志”功能，尤其是从 MySQL 8.0 开始，查询缓存（Query Cache）功能已被彻底移除。在 MySQL 5.7 及更早版本中，虽然存在查询缓存机制，但它不记录日志，仅通过状态变量反映命中情况。因此，无法像慢查询日志那样直接分析“查询缓存日志”。但你可以通过以下方式间接分析查询缓存的使用情况。
1. 确认查询缓存是否启用
在 MySQL 配置文件（如 my.cnf 或 my.ini）中查看是否有以下配置：
[mysqld] query_cache_type = ON query_cache_size = 64M
如果 query_cache_type 为 OFF 或 query_cache_size 为 0，则查询缓存未启用，所有查询都不会被缓存。
2. 查看查询缓存的状态变量
通过 SHOW STATUS 命令查看与查询缓存相关的统计信息：
SHOW STATUS LIKE 'Qcache%';
关键状态变量说明：
- Qcache_hits：查询缓存命中次数 —— 数值越高说明缓存效果越好
- Qcache_inserts：加入到缓存中的查询数量
- Qcache_queries_in_cache：当前缓存的查询数量
- Qcache_lowmem_prunes：因内存不足而删除的缓存条目数 —— 如果该值较高，说明 query_cache_size 设置过小
例如，若 Qcache_hits 很低而 Qcache_inserts 很高，说明缓存命中率低，可能查询变化多或缓存失效频繁。
3. 计算缓存命中率
使用以下公式评估查询缓存效率：
缓存命中率 = Qcache_hits / (Qcache_hits + Com_select)
其中 Com_select 可通过 SHOW STATUS LIKE ‘Com_select’ 获取。命中率低于 30% 通常说明查询缓存收益有限。
4. 结合慢查询日志分析高频查询
虽然不能直接看到哪些查询被缓存，但可以开启慢查询日志来识别执行频繁或耗时较长的 SELECT 语句：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; SET GLOBAL log_output = 'FILE'; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
然后使用 mysqldumpslow 或 pt-query-digest 分析慢日志，找出可受益于缓存的查询。
5. 替代方案：使用 Performance Schema 或通用日志
对于更细粒度的分析，可启用 Performance Schema 来监控语句执行情况：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'statements%';
之后从 events_statements_history 表中查看 SQL 执行记录，结合时间、执行计划等判断是否适合缓存。
注意：通用日志（general_log）会记录所有查询，但性能开销大，仅建议短时间开启用于诊断。
基本上就这些。由于查询缓存本身存在锁竞争问题，且对非完全一致的查询无效，在高并发场景下往往弊大于利。现代应用更推荐使用应用层缓存（如 redis、memcached）替代 MySQL 查询缓存。