慢查询通过触发临时表、排序溢出、长事务回滚段膨胀、中间文件生成及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 不足被迫频繁刷脏页。
安装、修复、更新或打包一个基于 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 条目这三个真实的空间消耗源头。
