MySQL 8.0+ 已彻底移除查询缓存（query_cache_type等参数），因其高并发下锁争用严重、命中率低；InnoDB Buffer Pool 成为数据页缓存主力，建议设为物理内存的50%~75%。
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 会分配线程级内存，这些参数控制单次操作能用多少内存，超限就落磁盘，性能断崖下跌。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见误区：
-
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 暴涨。
