delete慢因innodb需逐行更新主键及所有二级索引，索引越多越慢；优化核心是减少索引维护开销，通过临时删除非关键索引、分批删除、重建索引并执行analyze table更新统计信息。
DELETE 操作慢，不是因为 SQL 写得不够“狠”，而是因为每删一行，InnoDB 都得同步更新所有相关索引树——主键 + 每个二级索引各一棵。索引越多、越宽、越不匹配 WHERE 条件，删得就越慢。优化方向很明确：减少索引维护开销，而不是拼命调优单条语句。
哪些索引能临时删，哪些绝对不能碰
先执行 SHOW CREATE TABLE your_table，逐行看清楚每个索引的类型和用途：
-
PRIMARY KEY和UNIQUE KEY不能删——前者删不了，后者删了可能引入重复数据（比如订单号去重靠它） -
FOREIGN KEY约束依赖的索引（如KEY fk_user_id (user_id)）删会报错：Cannot drop index 'fk_user_id': needed in a foreign key constraint - 纯查询用的复合索引，比如
KEY idx_status_created (status, created_at)，且业务里没用它做唯一性校验或外键关联，才适合临时下线
别凭名字猜作用——idx_log_time 看起来像日志索引，但如果下游有定时任务靠它拉取未处理记录，删完就断流。
删索引 → 删数据 → 建索引，顺序错了全白干
三步必须严格按顺序执行，缺一不可：
- 删索引用
DROP INDEX idx_name ON table_name（不是ALTER TABLE ... DROP KEY，语法不同，写错直接报错） - 删数据阶段用分批，例如
DELETE FROM t WHERE id BETWEEN 100000 AND 200000 LIMIT 1000，避免单事务过大撑爆 redo log - 重建索引用
ALTER TABLE t ADD INDEX idx_new (col1, col2)（MySQL 5.7+ 推荐，比CREATE INDEX更少锁表）
如果先删数据再删索引，那删的过程中索引还在拖慢速度；如果删完不重建，后续所有查询都变慢，下次再删又得重走一遍流程。
删完重建索引后 COUNT(*) 还慢？不是索引没建好，是统计信息没更新
COUNT(*) 在 InnoDB 里默认走主键索引全扫描，但删重建过程不会自动刷新统计信息，优化器可能误判行数，选错执行计划。这不是性能问题，是元数据滞后：
- 手动触发采样：
ANALYZE TABLE your_table - 验证是否生效：
SELECT table_rows FROM information_schema.tables WHERE table_name = 'your_table'，数值应接近实际行数 - 别等自动采样——InnoDB 默认只在访问表时概率触发，大表可能几小时都不更新
分批删除时 WHERE 条件必须走索引，否则删得越快死得越早
哪怕你加了 LIMIT 1000，如果 WHERE 条件没走索引，MySQL 仍要全表扫描找这 1000 行，I/O 和 CPU 压力一点没减：
- 用
EXPLAIN DELETE FROM t WHERE status = 'old'看key字段是否非 NULL - 避免函数操作：
WHERE DATE(created_at) = '2023-01-01'会失效，改成WHERE created_at >= '2023-01-01' AND created_at - 复合索引顺序要匹配：若索引是
(a, b)，WHERE b = ?无法使用，必须WHERE a = ? AND b = ?或至少WHERE a = ?
真正卡住的往往不是删本身，而是删之前那一秒的全表扫描——这点最容易被忽略，也最难排查。
