OPTIMIZE TABLE不能直接用于生产环境在线整理，因其在InnoDB中本质是重建表并持有MDL_WRITE锁，阻塞所有DML和部分DDL，导致业务写入卡死数小时，引发超时、负载飙升及主从延迟突增。
为什么 OPTIMIZE TABLE 不能直接用于生产环境在线整理
因为 OPTIMIZE TABLE 在 InnoDB 中本质是执行 ALTER TABLE ... FORCE，会持有 MDL_WRITE 元数据锁，阻塞所有 DML（INSERT/UPDATE/DELETE）和部分 DDL，实际等于“逻辑停机”。尤其对大表（比如百 GB 级订单表），该操作可能持续数小时，期间业务写入完全卡住。
常见错误现象包括：应用报错 Lock wait timeout exceeded、监控显示 Threads_running 暴涨、慢查询堆积、主从延迟突增。
- MySQL 5.5/5.6 不支持并发 DML 下的
OPTIMIZE，必须规避 - 即使 MySQL 5.7+ 启用了
innodb_file_per_table，OPTIMIZE仍重建整表，无法跳过热分区 - 若表已按时间分区（如
PARTITION BY RANGE (clock)），盲目OPTIMIZE全表浪费资源
用 pt-online-schema-change 实现真正零锁表碎片整理
Percona Toolkit 的 pt-online-schema-change 是目前最稳妥的在线整理方案：它通过创建影子表、触发器同步增量、逐步拷贝数据的方式，全程不锁原表，DML 始终可用。
关键参数必须显式指定，否则容易翻车：
-
--alter "ENGINE=InnoDB"：这是触发碎片整理的核心——强制重建表结构，等效于OPTIMIZE效果 -
--chunk-size=1000：控制每次迁移行数，避免长事务拖垮主从；大表建议设为 500–2000 -
--max-load="Threads_running=25"：当SHOW STATUS LIKE 'Threads_running'超过阈值时自动暂停，保护负载 -
--critical-load="Threads_running=50"：达到该值立即中止，防止雪崩 -
--check-interval=5：每 5 秒检查一次负载和复制延迟
示例命令（整理 orders 表）：
pt-online-schema-change \ --user=root --password=xxx \ --host=localhost \ --database=prod_db \ --table=orders \ --alter "ENGINE=InnoDB" \ --chunk-size=1000 \ --max-load="Threads_running=25" \ --critical-load="Threads_running=50" \ --check-interval=5 \ --execute
备份与碎片整理合并操作的实操要点
不要先备份再整理，也不要先整理再备份——两者叠加会成倍放大 I/O 压力，极易触发磁盘满或 IO Wait 飙升。正确做法是：用逻辑备份工具直接导出“已整理”状态的数据。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
对于已启用 innodb_file_per_table 的实例，推荐组合使用：
- 对中小表（mysqldump --single-transaction --skip-triggers --no-create-info 导出数据，再导入新实例（相当于间接整理）
- 对大表且需保留分区结构：用
mysqlpump --parallel-schemas=2 --default-parallelism=4并发导出，比mysqldump快 3–5 倍 - 绝对避免在整理过程中跑全库
mysqldump --all-databases，它会拉取未整理的ibdata1共享表空间元信息，导致备份文件含大量无效碎片
特别注意：mysqlpump 在 MySQL 5.7+ 才可用；若用的是 5.5.47（如知识库中提到的环境），只能退回 mysqldump + pt-online-schema-change 分步走。
碎片是否真被清除了？必须验证的三个指标
执行完在线整理后，别只看命令返回 “Successfully altered `table`”，要立刻查三处：
-
SHOW TABLE STATUS LIKE 'orders'\G中的Data_free：从 GB 级降到 MB 级甚至 0 才算有效 -
SELECT table_name, data_free / data_length AS frag_ratio FROM information_schema.tables WHERE table_schema='prod_db' AND table_name='orders';：结果应 - OS 层
ls -lh /var/lib/mysql/prod_db/orders.ibd：文件大小应明显缩小（知识库案例中减少 29%）
最容易被忽略的是：Data_free 为 0 并不等于无碎片——InnoDB 的页内碎片（row fragmentation）仍可能存在，此时需结合 INFORMATION_SCHEMA.INNODB_METRICS 查 innodb_page_defrag_count 和 innodb_page_defrag_count 统计值，但该指标仅 MySQL 5.6.2+ 支持。
