MySQL 8.0+ 已彻底移除查询缓存模块，相关变量（如 query_cache_type）不存在，配置将导致启动失败；应转向应用层缓存、调优 innodb_buffer_pool_size、索引优化及合理设置临时表与连接内存参数。
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)。
