必须同步设置tmp_table_size和max_heap_table_size为相同值，因mysql取二者较小值作为内存临时表上限；若不一致（如tmp_table_size=512m但max_heap_table_size仍为默认16mb），则超限查询强制落盘，导致created_tmp_disk_tables激增及磁盘空间耗尽。
只改 tmp_table_size 基本没用，必须同步设好 max_heap_table_size，否则 MySQL 永远按两者中更小的那个值截断。
为什么改了 tmp_table_size 还报 “The table is full”
MySQL 判断是否能走内存临时表，不是看 tmp_table_size 多大，而是取 tmp_table_size 和 max_heap_table_size 的较小值。常见错误是：配置里写了 tmp_table_size = 512M，但忘了改 max_heap_table_size，它还卡在默认的 16MB（即 16777216 字节）。结果所有超过 16MB 的 GROUP BY 或 ORDER BY 查询，全被强制落盘——如果 @@tmpdir 又在根分区，ibtmp1 或 /tmp 就会一路暴涨到爆满。
- 执行
SELECT @@tmp_table_size, @@max_heap_table_size;确认两者数值是否一致（单位是字节） - 查
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，如果这个值每秒涨几十次，基本就是内存阈值被卡死了 - 别信慢日志里 “Using temporary” 就代表问题出在参数上——它也可能是因为
SELECT里带了TEXT字段，这种情况下再大的内存也拦不住落盘
在 /etc/my.cnf 里怎么写才真正生效
不能只写一行配置，也不能靠 SET GLOBAL 临时改——旧连接不生效，重启后又丢失。必须在配置文件里显式并列写两行，且值完全相等。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 在
/etc/my.cnf的[mysqld]段里加： tmp_table_size = 268435456max_heap_table_size = 268435456- 即 256MB，注意不要写
256M以外的单位，MB或G会解析失败 - 改完必须重启
mysqld；5.7.20+ 可用SET PERSIST持久化，但依然要重启才对已有连接生效
设多大才安全，又不引发 OOM
线上安全值范围是 64M～128M，8GB 内存机器起步用 64M，16GB 可设 128M，但绝不能超过可用内存的 20%～30%。还要把 per-connection 缓冲区一起算进去：
-
sort_buffer_size、join_buffer_size、read_buffer_size都是每个连接独占的 - 比如
max_connections = 300，sort_buffer_size = 4M，光排序缓冲就可能吃掉 1.2GB - 估算理论峰值内存：
innodb_buffer_pool_size + (sort_buffer_size + join_buffer_size + read_buffer_size) × max_connections，这个总和必须明显低于free -h显示的 available 值 - 建议保持
sort_buffer_size和join_buffer_size默认或设为 2M～4M，别按“最大可能”去配
最常被忽略的一点：哪怕你把两个参数都设对了，ibtmp1 文件也不会自动缩容。它会继续膨胀直到手动删掉并重启服务——这一步漏掉，磁盘照样爆满。
