MySQL 8.0 之后查询缓存已彻底移除
MySQL 5.7 默认仍启用
query_cache_type=1，但 8.0+ 版本中整个查询缓存模块（包括
query_cache_size、
query_cache_type等所有相关变量）已被完全删除。执行
SHOW VARIABLES LIKE 'query_cache%'将返回空结果。强行在配置文件中写入这些参数会导致 mysqld 启动失败或静默忽略——不是“不生效”，而是“不存在”。
替代方案：用应用层缓存 + 正确使用 InnoDB 缓冲池
查询缓存失效频繁、锁竞争高、且仅对完全相同的文本查询有效，实际生产中往往弊大于利。现代优化重心应转向：
innodb_buffer_pool_size应设为物理内存的 50%–75%（专用数据库服务器），确保热数据常驻内存，减少磁盘 I/O 避免全表扫描：为高频
WHERE、
JOIN、
ORDER BY字段建立合适索引 用 Redis 或 Memcached 缓存应用层聚合结果（如用户首页 feed、统计报表），控制缓存粒度与失效逻辑 若仍需 SQL 级缓存语义，可借助
SELECT SQL_CACHE ...（5.7 及更早）——但该语法在 8.0+ 已被拒绝解析
检查与调优关键内存参数（8.0+）
以下参数直接影响查询响应速度和并发能力，需结合 workload 调整：
innodb_buffer_pool_size：核心参数，必须优先调优；动态调整需重启或在线 resize（MySQL 5.7+ 支持
SET GLOBAL innodb_buffer_pool_size = N，但需满足最小页数限制）
innodb_log_file_size：影响崩溃恢复时间与写性能；增大可提升并发写吞吐，但会延长 recovery 时间；建议单个日志文件 ≥ 256MB，总和 ≤ 4GB
sort_buffer_size和
join_buffer_size：每个连接独占，不宜设过大（如 > 4MB），否则高并发下易触发 OOM；优先靠索引优化消除 filesort / Block Nested-Loop
tmp_table_size和
max_heap_table_size：控制内存临时表上限，二者需设为相同值；超过则自动转为磁盘临时表（
Created_tmp_disk_tables值升高即为信号）
SHOW GLOBAL STATUS LIKE 'Created_tmp%'; SHOW VARIABLES LIKE '%buffer%'; SHOW VARIABLES LIKE '%table_size%';
容易被忽略的隐性内存开销
除了显式配置项，以下行为也会显著消耗内存且不易察觉：
大量短连接：每个连接至少占用 ≈ 256KB（含线程栈、网络缓冲区等），wait_timeout过长 + 应用未复用连接 → 内存缓慢泄漏 大结果集未及时 fetch：执行
SELECT * FROM huge_table后只读前几行却未关闭游标，结果集仍驻留内存直至连接断开 JSON 列或长文本字段：
JSON_EXTRACT()或
SUBSTRING()在内存中复制完整字段内容，即使只取其中几个字节 预编译语句未释放：
PREPARE stmt FROM ...后未配对
DEALLOCATE PREPARE stmt，statement 对象持续占用内存
查内存真实占用，别只看
innodb_buffer_pool_size：用
SHOW ENGINE INNODB STATUS\G中的
Buffer pool hit rate和
Memory段，再配合系统级工具如
pmap -x $(pgrep mysqld)。
