慢查询通过触发临时表、排序溢出、长事务回滚段膨胀、中间文件生成及binlog/undo日志累积，隐性消耗磁盘空间；需结合performance_schema等待事件、PROCESSLIST状态、tmpdir文件分析及INNODB_TRX/ROLLBACK_SEGMENTS定位真实空间占用源。

为什么慢查询会悄悄吃掉磁盘空间

慢查询本身不直接写磁盘，但它们常触发大量临时表、排序缓冲区溢出、未提交的大事务回滚段膨胀——这些都会在 ibdata1 或独立表空间中持续申请页，且释放滞后。更隐蔽的是：某些慢查询（如 SELECT ... INTO OUTFILE、CREATE TABLE AS SELECT）会在磁盘生成中间文件；而带 GROUP BY 或 ORDER BY 的长时查询，若 sort_buffer_size 不足，会反复创建/删除 /tmp/#sql_* 临时文件，碎片化加剧空间浪费。

用 performance_schema 抓“不记录在 slow_log 里的慢操作”

默认开启的 slow_query_log 只捕获执行完成的 SQL，而卡在 I/O 等待、锁等待、内存分配阶段的查询可能根本没进日志。必须依赖 performance_schema 的等待事件：

• 确认已启用：检查 performance_schema=ON，并打开关键消费者：UPDATE setup_consumers SET ENABLED='YES' WHERE NAME IN ('events_waits_current', 'events_waits_history_long');
• 查正在卡住的线程：SELECT THREAD_ID, EVENT_NAME, TIMER_WAIT/1e9 AS wait_s FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE 'wait/io/file/%' AND TIMER_WAIT > 1000000000 ORDER BY TIMER_WAIT DESC LIMIT 5;
• 重点盯 wait/io/file/innodb/innodb_data_file 和 wait/io/file/myisam/dfile —— 这类等待超过 2 秒，基本说明该线程正在疯狂读写数据文件，极可能是大表扫描或排序导致的空间隐性消耗。

结合 processlist 和磁盘 I/O 状态交叉验证

SHOW PROCESSLIST 中状态为 Copying to tmp table、Creating sort index、Writing to net（实际是刷脏页慢）的线程，如果对应 top 中 %wa 长期 > 50%，就不是 SQL 逻辑慢，而是磁盘扛不住了——此时该线程很可能正在把几 GB 的结果集往磁盘临时目录 dump，或因 buffer pool 不足被迫频繁刷脏页。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 快速定位这类线程：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE STATE IN ('Copying to tmp table', 'Creating sort index', 'Writing to net') AND TIME > 30;
• 立刻检查临时目录：SELECT @@tmpdir;，然后在系统层运行 du -sh $(@@tmpdir)/* | sort -rh | head -5，看是否有异常大的 #sql_* 或 mysqltmp_* 文件。
• 注意：RDS 用户无法直接访问 @@tmpdir 文件系统，此时应改查 performance_schema.file_summary_by_instance 中 FILE_NAME 含 tmp 的条目，观察 SUM_NUMBER_OF_BYTES_WRITE 是否突增。

别忽略慢查询引发的 binlog 和 undo log 膨胀

一个执行 5 分钟才结束的 UPDATE 慢查询，会持有一个长达 5 分钟的事务，期间所有被修改的行版本都保留在 undo log 中；同时，binlog 会完整记录该事务的最终状态（非行级变更），若事务中途失败回滚，undo log 仍需保留直到 purge 线程清理——这会导致 ibdata1 或独立 undo 表空间持续增长，且不会反映在慢日志里。

• 查长事务：SELECT trx_id, trx_started, trx_state, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
• 关联查其占用的 undo 页数：SELECT r.trx_id, r.n_undo_logs, r.undo_log_entries FROM information_schema.INNODB_TRX t JOIN performance_schema.threads th ON t.trx_mysql_thread_id = th.processlist_id JOIN performance_schema.events_transactions_current e ON th.thread_id = e.thread_id JOIN performance_schema.events_statements_current s ON e.event_id = s.event_id JOIN information_schema.INNODB_ROLLBACK_SEGMENTS r ON t.trx_id = r.trx_id;（需 MySQL 8.0.33+）
• 关键信号：如果 trx_state = 'RUNNING' 且 undo_log_entries > 100000，该事务大概率正在拖垮磁盘空间。

真正危险的不是执行慢的 SQL，而是那些“看起来执行完了，其实后台还在疯狂写磁盘”的查询——它们绕过慢日志监控，却持续向 ibdata1 或 binlog 目录倾倒数据。排查时必须跳出 SQL 执行时间本身，盯住 I/O 等待、临时文件、undo 条目这三个真实的空间消耗源头。