必须同步设置tmp_table_size与max_heap_table_size为相同值，否则以较小者为准；xampp中需修改d:\xampp\mysql\bin\my.ini的[mysqld]段并重启服务，且需验证created_tmp_disk_tables增长情况。
tmp_table_size 调不上去？先看 max_heap_table_size 是否同步
在 XAMPP 里改 tmp_table_size 却没效果，大概率是被 max_heap_table_size 卡住了。MySQL 实际允许的内存临时表大小，取这两个值中的较小者——哪怕你把 tmp_table_size 设成 256M，而 max_heap_table_size 还是默认的 16M，那最终上限就是 16M。
实操建议：
- 进 MySQL 执行：
SELECT @@tmp_table_size, @@max_heap_table_size;，确认两者是否相等 - 若不一致，必须同时设：
SET GLOBAL tmp_table_size = 67108864;和SET GLOBAL max_heap_table_size = 67108864;（即 64MB） - XAMPP 的配置文件路径通常是
D:\xampp\mysql\bin\my.ini（不是系统目录下的my.ini），在[mysqld]段下添加两行：
[mysqld] tmp_table_size = 67108864 max_heap_table_size = 67108864
改完务必重启 MySQL 服务（用 XAMPP 控制面板点 stop/start）。
为什么改了还是走磁盘临时表？常见硬限制条件
即使参数调得再大，只要查询本身触发了强制落盘规则，tmp_table_size 就完全失效。这不是配置问题，而是 MySQL 的行为约束。
典型场景包括：
- 查询中用了
TEXT或BLOB类型字段 → 直接跳过内存表，写磁盘 -
GROUP BY或ORDER BY字段没索引，且结果集大 → 内存预估失败，降级为磁盘表 - 语句含
UNION、DISTINCT、子查询，且涉及多列排序 → 容易突破内存估算阈值 - 连接建立后才改
GLOBAL参数 → 旧连接仍按原值运行，需重连或单独执行SET SESSION tmp_table_size = ...
验证方式：查慢日志里是否有 Using temporary; Using filesort，再配合 SHOW GLOBAL STATUS LIKE 'Created_tmp%'; 看 Created_tmp_disk_tables 是否持续增长。
XAMPP 低配环境（如 2GB 内存）的安全值怎么定？
XAMPP 默认配置偏“通用”，对低内存机器非常不友好。盲目把 tmp_table_size 拉到 256M，可能让几个并发连接就把物理内存打满，触发 swap 甚至 MySQL 崩溃。
推荐做法：
- 先压低
innodb_buffer_pool_size（XAMPP 默认 128M，2GB 机器建议设为32M） - 把
max_connections从默认 151 改为30左右 -
tmp_table_size和max_heap_table_size合计建议 ≤ 64M（例如各设为67108864） - 避免设过高
sort_buffer_size或read_buffer_size，它们是每连接独占，64K 足够开发用
记住：每个连接都可能分配一块 tmp_table_size 大小的内存，不是全局共享池。
改完怎么验证真正生效？别只看 VARIABLES
SHOW VARIABLES LIKE 'tmp_table_size' 显示的是当前会话看到的值，不代表实际生效逻辑。真正要看的是运行时行为。
关键验证步骤：
- 执行一次明显会建临时表的 SQL，比如：
SELECT DISTINCT id FROM your_table ORDER BY id; - 立刻查状态：
SHOW GLOBAL STATUS LIKE 'Created_tmp%'; - 观察
Created_tmp_disk_tables是否增长 —— 如果它没动，而Created_tmp_tables增了，说明走的是内存表 - 对比比值：
Created_tmp_disk_tables / Created_tmp_tables * 100%应该 ≤ 20%，才算调参有效
最容易被忽略的一点：XAMPP 的 my.ini 文件可能被多个位置存在（比如 Windows 系统目录下也有一个），但只有 D:\xampp\mysql\bin\my.ini 是 MySQL 启动时真正读取的配置文件。改错地方等于白改。
