MySQL表碎片是InnoDB引擎因频繁DELETE/UPDATE产生的空闲页和非连续存储空间，Python脚本不能直接清理，只能安全调度OPTIMIZE TABLE等原生命令，并需通过碎片率（DATA_FREE/DATA_LENGTH＞20%）、表大小（＞10MB）、引擎类型（InnoDB）等条件精准筛选目标表，配合超时控制、错误捕获与幂等设计实现可靠运维。
MySQL表碎片是什么，为什么Python脚本不能直接“清理”它
MySQL表碎片不是Python能直接操作的文件级垃圾，而是InnoDB引擎在频繁DELETE/UPDATE后产生的空闲页和非连续存储空间。Python脚本本身不参与存储引擎层面的整理，它只能触发MySQL原生命令——比如OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB。误以为用Python“删数据+重建索引”就能等效清理，结果常导致锁表时间不可控、主从延迟飙升，甚至OOM。
真正要做的，是让Python可靠地调度、监控、规避风险地执行这些SQL命令：
-
OPTIMIZE TABLE会重建表并更新统计信息，但会锁表（尤其大表），且在MySQL 8.0+中对InnoDB默认改用ALGORITHM=INPLACE，但仍需足够临时空间 - 如果启用了
innodb_file_per_table=OFF，OPTIMIZE对系统表空间无效，必须先确认配置 - 不要在业务高峰跑，更别用
SELECT * FROM information_schema.TABLES无差别遍历所有表——有些小表碎片率0.1%，优化纯属浪费IO
怎么用Python判断哪些表真需要OPTIMIZE
碎片率不是看磁盘占用，而是计算DATA_FREE / DATA_LENGTH（单位字节），这个比值超过20%才值得干预。直接查information_schema.TABLES就行，但注意过滤条件：
- 只查
ENGINE='InnoDB'的表，MyISAM用REPAIR TABLE逻辑不同 - 排除
TABLE_SCHEMA为'mysql'、'information_schema'等系统库 - 加
AND DATA_LENGTH > 10485760（10MB），太小的表即使碎片率高也无实际收益 - 避免
DATA_FREE IS NULL的表（比如刚创建未写入的表）
示例SQL片段（Python里拼进cursor.execute()）：
立即学习“Python免费学习笔记（深入）”；
SELECT TABLE_SCHEMA, TABLE_NAME,
ROUND(DATA_FREE / DATA_LENGTH * 100, 2) AS frag_pct
FROM information_schema.TABLES
WHERE ENGINE = 'InnoDB'
AND TABLE_SCHEMA NOT IN ('mysql', 'performance_schema', 'information_schema')
AND DATA_LENGTH > 10485760
AND DATA_FREE IS NOT NULL
AND DATA_FREE / DATA_LENGTH > 0.2;如何安全执行OPTIMIZE并防止脚本中途失败
直接cursor.execute("OPTIMIZE TABLE ...")极危险：网络断开、超时、锁等待都会让连接卡住，后续语句全失效。必须用带重试、超时、事务隔离的封装：
- 给每个
OPTIMIZE加timeout=3600（1小时），用mysql.connector的connection.pool或pymysql的connect(timeout=...) - 执行前先
SELECT @@innodb_lock_wait_timeout，确保不是默认50秒——大表可能需要调到300秒以上 - 捕获具体错误：
"Lock wait timeout exceeded"、"Deadlock found"、"Lost connection"，记录日志并跳过该表，而不是整个脚本退出 - 每优化完一张表，
SELECT ROW_COUNT()确认是否生效（返回-1表示被跳过，0表示无变化，正数才是真实重建行数）
定时任务部署时最容易忽略的三个点
用crontab跑Python脚本看似简单，但线上出问题基本都栽在这三处：
- 环境变量缺失：cron默认
PATH极短，找不到python3或依赖包。必须在crontab里写绝对路径，比如/usr/bin/python3 /opt/clean/frag_clean.py - 数据库连接池没关：脚本末尾漏掉
conn.close()，多次运行后MySQL报"Too many connections" - 没做幂等性：某次crontab执行卡住，下次又触发，同一张表被重复
OPTIMIZE。建议在脚本开头建一张cleanup_log表，每次执行前查WHERE table_name = ? AND DATE(exec_time) = CURDATE()，已执行则跳过
碎片清理不是越勤越好，一周一次足够；真正关键的是把“哪些表、什么条件下、以什么参数执行”这件事钉死，而不是追求全自动。
