不能直接缩小行锁范围。OPTIMIZE TABLE 在 InnoDB 中本质是重建表，可释放碎片、重排索引，但锁范围由语句类型、隔离级别和索引覆盖决定；仅当空洞导致执行计划偏差时，才可能间接减少锁定行数。
MySQL 的 OPTIMIZE TABLE 真的能修复索引空洞并缩小锁范围吗？
不能直接缩小行锁范围。OPTIMIZE TABLE 在 InnoDB 中本质是重建表（ALTER TABLE ... FORCE），会释放碎片、重排聚簇索引和二级索引，但它不改变事务执行时的锁行为逻辑。锁范围由语句类型（如 UPDATE ... WHERE id > 100）、隔离级别、索引覆盖情况共同决定，不是靠“填空洞”就能压缩的。
什么情况下 OPTIMIZE TABLE 可能间接影响锁表现？
仅当空洞严重导致查询走不到有效索引、被迫全扫描或使用低效索引时，OPTIMIZE TABLE 重排后可能让优化器选中更精确的索引路径，从而减少实际锁定的行数。但这属于“修复执行计划偏差”，不是锁机制本身的调整。
- 表长期大量 DELETE + INSERT，且
innodb_file_per_table=ON，物理碎片多 →OPTIMIZE TABLE后 B+ 树层级变浅，范围扫描更快，持有锁时间缩短 - 二级索引页内空洞多，导致
SELECT ... FOR UPDATE扫描更多索引页 → 重建后页利用率提高，扫描页数下降 - 但若 SQL 本身没走索引（例如
WHERE status = 'pending'无索引），OPTIMIZE TABLE完全无效
真正防止锁范围扩大的实操手段
与其依赖 OPTIMIZE TABLE，不如从 SQL 和索引设计入手控制锁粒度：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确保
WHERE条件命中最左前缀索引，避免隐式类型转换或函数操作（如WHERE DATE(create_time) = '2024-01-01'） - 用
EXPLAIN验证是否走了预期索引，重点关注key、rows、Extra字段 - 对高频更新字段建单独索引，避免因索引缺失导致全表扫描加锁
- 批量更新改用主键分片：比如
UPDATE t SET x=1 WHERE id BETWEEN 1000 AND 1999，比WHERE status='old'更可控 - 确认事务隔离级别：READ COMMITTED 下非唯一条件的
UPDATE不会锁间隙（gap lock），而 REPEATABLE READ 会
OPTIMIZE TABLE 的真实代价和触发时机
它会阻塞 DML（INSERT/UPDATE/DELETE），且重建期间占用双倍磁盘空间（原表 + 新表）。线上表慎用，尤其大表：
- 只在
DATA_FREE显著（> 表数据大小 20%）且业务低峰期执行 - 优先考虑在线 DDL 工具（如
pt-online-schema-change或 MySQL 8.0+ 的ALGORITHM=INPLACE）替代 - 监控
information_schema.INNODB_SYS_TABLES中的FREE_SPACE字段，比看SHOW TABLE STATUS更准 - 定期
OPTIMIZE TABLE是反模式 —— 碎片是常态，关键在避免让碎片引发错误执行计划
索引空洞本身不扩大锁，但会让优化器“看走眼”。真正要盯的是执行计划是否稳定、索引是否被正确使用，而不是隔三差五跑一遍 OPTIMIZE TABLE。
