MySQL用tmp_table_size和max_heap_table_size二者中的较小值作为内存临时表的硬上限；若不设为相同值（如均设为64M～256M），易因阈值过低触发磁盘落盘，导致性能下降或/tmp、ibtmp1撑爆。
tmp_table_size 和 max_heap_table_size 哪个起作用？
MySQL 用两者中的较小值作为内存临时表的硬上限。比如你设了 tmp_table_size = 64M，但 max_heap_table_size = 16M，那实际能用的只有 16MB——超过就必然落盘。这个判断在查询执行中动态发生，不是建表时决定的。
常见错误是只调大 tmp_table_size，却忘了 max_heap_table_size 默认只有 16MB（很多生产环境没改过），结果 MEMORY 临时表刚塞几万行 VARCHAR 就触发 converting HEAP to ondisk 状态。
- 两个参数都是会话级变量，
SET SESSION tmp_table_size = 128 * 1024 * 1024才生效，全局设置不影响已连接会话 - 高并发下每个连接独占一份内存配额，总开销是连接数 × 较小值，别把
max_heap_table_size设得太大导致 OOM -
SHOW VARIABLES LIKE '%table_size%'查的是当前会话值，不是全局值
为什么选 MyISAM 而不是 InnoDB 作磁盘后备？
MySQL 5.7.6 之前默认用 MyISAM，之后才通过 internal_tmp_disk_storage_engine 控制，默认改为 InnoDB。但如果你用的是老版本，或显式设了 SET SESSION internal_tmp_disk_storage_engine = 'MyISAM'，就会回落到 MyISAM。
更隐蔽的情况是：会话里执行过 SET SESSION default_storage_engine = 'MyISAM'，而 MySQL 创建磁盘临时表时会复用该设置——哪怕你没动过 internal_tmp_disk_storage_engine。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查当前会话磁盘临时表引擎：
SELECT @@session.internal_tmp_disk_storage_engine - MyISAM 磁盘临时表不支持事务、无崩溃恢复，查询中途被 kill 容易留下损坏的 .MYD/.MYI 文件
- InnoDB 磁盘临时表走
ibtmp1共享空间，受 redo log 保护，异常中断后能自动清理
哪些 SQL 操作会让 MEMORY 表瞬间爆内存？
不是数据行数多才爆，而是字段定义长度和中间结果体积共同决定。比如 SELECT * + ORDER BY created_at，哪怕只返回 10 行，只要某列是 TEXT 或 VARCHAR(2000)，MySQL 就按最大可能长度估算内存占用，极易超限。
- GROUP BY 后聚合字段含大字段（如
GROUP_CONCAT(content)） - 多表 JOIN 后再 ORDER BY，且排序字段不在驱动表索引覆盖范围内
- WHERE 条件类型不一致引发隐式转换，导致索引失效、全表扫描进内存
- LIMIT 大偏移量（如
LIMIT 50000, 20）+ 无覆盖索引，MySQL 得把前 50020 行全载入内存再丢弃
怎么确认真是 MEMORY 落盘拖慢了查询？
SHOW PROCESSLIST 里看到 converting HEAP to ondisk 或 Copying to tmp table on disk 是直接证据，但这个状态一闪而过，容易错过。更可靠的方式是监控状态变量：
- 执行前记下
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'的值，执行后对比增量 - 用
SHOW PROFILE FOR QUERY N（N 是SHOW PROFILES中的 ID），看Copying to tmp table on disk阶段耗时占比 - 注意：
EXPLAIN完全看不到这个过程——它不模拟内存压力，只输出优化器预估的执行计划
真正麻烦的是那些“看起来很快但偶尔卡死”的查询：它们多数时候内存够用，只在并发高峰或数据分布突变时才落盘，这种非确定性问题最难复现和定位。
