MySQL 查询缓存（Query Cache）已彻底移除，别再配置 query_cache_type
MySQL 8.0 起，
query_cache_type、
query_cache_size等所有查询缓存相关变量已被删除。如果你在 8.0+ 版本中看到
Unknown system variable 'query_cache_type'错误，不是配置错了，是它根本不存在了。
官方移除原因很直接：在高并发写入场景下，查询缓存的锁争用和失效开销远大于收益；且它只对完全相同的 SQL 文本（包括空格、大小写、连接顺序）命中，实际业务中命中率极低。
5.7 是最后一个支持查询缓存的大版本，但默认已是OFF即使开启，只要表有任意写操作（
INSERT/
UPDATE/
DELETE），该表所有缓存条目立即失效
SELECT SQL_NO_CACHE ...这类提示在 8.0+ 中虽不报错，但完全被忽略
InnoDB 缓冲池（Buffer Pool）才是真正的“SQL 执行内存主力”
执行
SELECT时，数据页从磁盘加载到内存的过程由 InnoDB Buffer Pool 完成；执行
UPDATE或
INSERT时，修改也先发生在 Buffer Pool 中，再异步刷回磁盘。它的大小直接决定多数 SQL 的响应速度和内存占用。
关键点：
Buffer Pool 不缓存 SQL 文本或执行计划，只缓存数据页（.ibd文件中的 16KB 页面）和索引页 默认大小通常仅 128MB，生产环境务必调大——建议设为物理内存的 50%~75%，但不超过
innodb_buffer_pool_size上限（如 64GB 机器可设 40G） 修改后需重启 MySQL 生效（8.0.22+ 支持在线调整，但仍有碎片限制） 可通过
SHOW ENGINE INNODB STATUS\G查看
Buffer pool hit rate，持续低于 95% 就该扩容了
执行计划生成与临时表内存：sort_buffer_size
和 tmp_table_size
的真实作用
当 SQL 需要排序（
ORDER BY）、分组（
GROUP BY）或创建内部临时表时，MySQL 会分配线程级内存，这些参数控制单次操作能用多少内存，超限就落磁盘，性能断崖下跌。
常见误区：
sort_buffer_size不是“排序总内存”，而是每个需要排序的线程独占一块（非全局共享），设太大反而浪费；一般 256KB~4MB 足够，超大结果集排序应靠索引覆盖而非调大该值
tmp_table_size和
max_heap_table_size必须设为相同值，否则以较小者为准；超过该值的内存临时表会自动转成磁盘
MyISAM表（
Created_tmp_disk_tables计数器上升） 查看是否频繁落盘：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';，若
Created_tmp_disk_tables / Created_tmp_tables > 10%，说明临时表内存不足
执行过程中真正消耗内存的几个典型场景
不是所有 SQL 都吃内存，但以下情况会显著拉升单条语句的内存峰值：
SELECT * FROM huge_table ORDER BY unindexed_column：触发全表扫描 + 内存排序，若结果集超
sort_buffer_size，降级为归并排序并大量使用磁盘
JOIN多张大表且无有效索引：驱动表结果集在内存中构建哈希表（
hash_join_buffer_size控制），可能暴涨至 GB 级
GROUP BY配合
WITH ROLLUP或多层嵌套聚合：内部临时表膨胀快，极易突破
tmp_table_size使用窗口函数（
ROW_NUMBER()、
RANK()）处理百万行：MySQL 8.0+ 仍需将分区数据暂存内存，无索引时内存消耗陡增
查当前连接内存使用：
SELECT * FROM performance_schema.memory_summary_by_thread_by_event_name WHERE EVENT_NAME LIKE 'memory/sql/%' ORDER BY SUM_ALLOCATED DESC LIMIT 10;—— 注意这是按线程维度统计，不是全局。
Buffer Pool 管理的是“热数据页”，而 sort/tmp 相关 buffer 管理的是“计算过程”，两者生命周期、作用域、调优逻辑完全不同。混淆它们，就会一边狂调
innodb_buffer_pool_size一边看着
Created_tmp_disk_tables暴涨。
