直接DELETE百万行会卡死或超时，因InnoDB需维护所有索引B+树、写undo/redo log、更新MVCC版本链，索引越多、数据越分散，I/O与锁竞争越严重；非唯一WHERE条件还引发间隙锁阻塞，易触发Lock wait timeout exceeded。
为什么直接 DELETE 百万行会卡死或超时
因为每删一行，InnoDB 都要维护所有相关索引的 B+ 树结构，还要写 undo log、redo log，触发 MVCC 版本链更新。索引越多、数据越分散，I/O 和锁竞争越严重，实际可能跑几小时甚至被 kill。
- 主键索引 + 3 个二级索引？删除操作实际要修改 4 棵树，且二级索引叶子节点不聚簇，随机 I/O 更猛
- 事务未提交前，被删行的间隙锁（gap lock）可能阻塞其他写入，尤其在
WHERE条件非唯一时 - MySQL 8.0 默认
innodb_lock_wait_timeout=50，但大删期间锁等待极易超时，报错Lock wait timeout exceeded
删索引真能提速？哪些索引该删、哪些不能动
删的是「非主键、非外键、非唯一约束依赖」的二级索引。主键索引删不了，外键索引删了会报错 Cannot drop index 'xxx': needed in a foreign key constraint，唯一索引如果业务靠它防重，删完再重建窗口期可能引入脏数据。
- 先查清楚：执行
SHOW CREATE TABLE `your_table`，看哪些是KEY（普通索引）、哪些是UNIQUE KEY或PRIMARY KEY - 安全删除范围：只有
KEY idx_status_created (status, created_at)这类纯查询用的复合索引才适合临时下线 - 别碰：
KEY uk_order_no (order_no)（唯一索引）、KEY fk_user_id (user_id)（外键索引）
删索引 → 删数据 → 建索引，三步顺序不能乱
顺序错了就白忙：比如先删数据再删索引，那删数据时索引还在拖慢速度；如果删完索引不重建，后续查询性能雪崩，而且下次再删又得重复一遍流程。
- 删索引命令必须用
DROP INDEX idx_name ON table_name，别用ALTER TABLE ... DROP KEY（语法不同，容易写错） - 删数据推荐分批：用
DELETE FROM t WHERE id BETWEEN 100000 AND 200000 LIMIT 1000循环跑，避免单事务过大撑爆innodb_log_file_size - 重建索引要用
ALTER TABLE t ADD INDEX idx_new (col1, col2)，别用CREATE INDEX（老版本 MySQL 可能加表级锁）
重建索引后为什么 SELECT COUNT(*) 还很慢
因为 COUNT(*) 在 InnoDB 里默认走主键索引全扫描，删重建过程不会自动更新统计信息，优化器可能误判行数，选错执行计划。不是索引没建好，是元数据滞后了。
- 手动更新：执行
ANALYZE TABLE your_table，让 MySQL 重新采样页和索引分布 - 验证是否生效：查
SELECT table_rows FROM information_schema.tables WHERE table_name = 'your_table'，数值应接近实际 - 注意：如果表有上亿行，
ANALYZE TABLE本身也可能耗时几分钟，别在高峰期跑
SHOW INDEX 就动手，结果 DROP INDEX 报错才发现有隐式外键，或者删完发现订单号重复插入成功了。 
