innodb不支持禁用索引加速delete，因其必须同步维护所有索引以保障acid；disable keys仅对myisam有效且不适用于delete；真正有效的优化是确保where走索引、分批小事务提交、调优缓冲池与日志参数。
禁用索引不能直接加速 DELETE，反而可能让操作更危险、更慢——除非你用的是 MyISAM 引擎，且明确知道后果。
为什么 MySQL 的 InnoDB 不支持“禁用索引”来加速 DELETE
InnoDB 在执行 DELETE 时，会同步维护所有相关索引（主键 + 二级索引），这是 ACID 的一部分。你无法像 SQL Server 那样用 TABLOCK 或临时禁用索引；ALTER TABLE ... DISABLE KEYS 对 InnoDB 完全无效，该语句只对 MyISAM 生效。
常见错误现象：
- 执行 ALTER TABLE t DISABLE KEYS 后删数据，发现速度毫无提升，EXPLAIN 仍显示全表扫描；
- 误以为禁用了索引，结果 WHERE 条件没走索引，导致锁住全表几小时；
- 在 InnoDB 上强行用 DISABLE KEYS，命令静默失败，但用户不查返回值，以为生效了。
- MyISAM 可用
DISABLE KEYS，但仅对INSERT有效，对DELETE无加速作用（因为删除仍需定位行） - InnoDB 唯一能“绕过索引维护”的方式是：用
TRUNCATE TABLE（但它是 DDL，不可回滚、重置自增、不走 WHERE） - 真正影响 DELETE 速度的，是 WHERE 条件是否命中索引、事务大小、缓冲池是否够用
替代方案：用 DROP + RECREATE 替代大范围 DELETE（适用场景）
当你要删除 >80% 的数据（比如清理历史日志表），物理重建比逐行 DELETE 快得多，且能彻底释放空间、重建最优索引结构。
操作步骤：
- 新建空表
new_table，结构与原表一致（SHOW CREATE TABLE old_table拿 DDL） - 把要保留的数据 INSERT INTO … SELECT … WHERE 条件（确保 WHERE 走索引）
- 原子替换：
RENAME TABLE old_table TO old_bak, new_table TO old_table - 验证后删备份表：
DROP TABLE old_bak
注意点：
- 替换期间原表名不可用，业务需短暂中断或走读写分离路由
- INSERT INTO ... SELECT 是单事务，大表需控制批次或加 ORDER BY primary_key LIMIT 避免长事务
- 若原表有外键，需先 DROP FOREIGN KEY，重建后再加回
真正有效的 DELETE 加速手段（InnoDB 环境）
别碰索引开关，盯紧这三件事：
-
WHERE 必须走索引：用
EXPLAIN DELETE FROM t WHERE x = ?确认type是range或ref，不是ALL；避免在 WHERE 中用函数（如DATE(create_time)）、隐式类型转换 -
分批提交 + 小事务：单次删 500–1000 行（非 10 万），配合
COMMIT，避免 MDL 锁和 undo log 膨胀；可用存储过程循环：DELETE FROM t WHERE id BETWEEN ? AND ? LIMIT 1000 -
删前调优配置：增大
innodb_buffer_pool_size（建议设为物理内存 70%）、确认innodb_flush_log_at_trx_commit = 1（安全前提下不建议关）
典型陷阱：
- 以为加了索引就万事大吉，结果索引列上有大量 NULL 值，优化器弃用索引
- 分批逻辑写成 WHERE id > last_id ORDER BY id LIMIT 1000，但没加 id 上的索引，导致每次扫描都变慢
SQL Server 中的“禁用索引”确实可用，但仅限非聚集索引
SQL Server 支持 ALTER INDEX idx_name ON table_name DISABLE，对批量 DELETE 有实际效果——前提是你要删的数据占比高，且该索引不用于 WHERE 条件。
实操要点：
- 只禁用非聚集索引（
DISABLE对聚集索引无效） - 必须提前
SET XACT_ABORT ON，否则禁用后事务中出错可能卡死 - 删完立刻
ALTER INDEX ... REBUILD，否则后续查询性能暴跌 - 禁用期间，任何试图使用该索引的查询会报错：
The query processor could not produce a query plan because the index 'xxx' is disabled.
这个操作在 OLAP 类场景（如夜间 ETL 清洗）可行，但在 OLTP 生产环境需严格评估锁表时间和业务容忍度。
最常被忽略的一点：DELETE 的瓶颈往往不在索引本身，而在 binlog 写入、redo log 刷盘、以及 MVCC 版本链清理。与其纠结“禁不禁索引”，不如先用 SHOW ENGINE INNODB STATUS 看当前事务等待点，再决定从哪下手。
