INSERT变慢主因是索引同步更新：每增1行，需在所有相关B+树索引中各执行1次插入（含页分裂等），5个索引即5倍I/O与CPU开销；唯一索引校验更重；长字段索引易膨胀；低区分度字段前置加深树高；冗余索引（如已有(user_id,status,created_at)再建(user_id)）徒增负担；删索引风险高于建索引，须先验证；索引过多反致优化器误选或评估开销增大。
INSERT变慢不是错觉，是索引在同步更新
每次 INSERT，MySQL 不只是写一行数据，还要在所有相关索引的 B+ 树里各做一次插入——包括可能的页分裂、合并和指针调整。你加了 5 个索引，它就得多跑 5 套完整路径，不是“多算一次”，是“多做五次磁盘 I/O + CPU 计算”。
常见错误现象：SHOW PROCESSLIST 里大量线程卡在 update 或 insert 状态；innodb_row_lock_waits 指标突增；单条插入耗时从 0.2ms 跳到 2ms 以上。
- 唯一索引额外要校验重复值，比普通索引更重
- TEXT/VARCHAR(255) 字段建索引，若实际值很长，索引页膨胀快，分裂更频繁
- 联合索引顺序不合理（比如把
status这种低区分度字段放最前），会导致树更深、写入路径更长
哪些索引其实根本没被用上
很多索引是历史遗留、开发随手加、或某次临时优化后忘了删。它们不服务任何查询，只持续拖累写入性能。
判断依据不能靠感觉，得看真实统计：
- MySQL 8.0+：查
sys.schema_unused_indexes，它基于performance_schema统计，直接列出长期未被任何查询使用的索引 - 通用方式：对比
information_schema.STATISTICS中的索引名 和 所有慢查询日志 /EXPLAIN结果中实际出现的key列，找“从不出现”的 - 注意联合索引的前缀覆盖：已有
(user_id, status, created_at)，再建(user_id)或(user_id, status)就是冗余；但(status, user_id)不一定冗余，因最左前缀规则不同
ALTER TABLE ADD INDEX 会锁表，但 DROP INDEX 更危险
ALTER TABLE ... ADD INDEX 在大表上执行，即使 MySQL 5.6+ 支持 ALGORITHM=INPLACE，仍需元数据锁等待，且阻塞后续 DML。而 DROP INDEX 表面轻量，实则风险更高。
- 删错索引可能让某条关键查询从 10ms 慢成 10s，尤其当应用依赖某个索引支撑
WHERE+ORDER BY场景时 -
DROP INDEX idx_name ON t在 MySQL 5.7 默认走 INPLACE，但若索引含全文或空间类型，则强制 COPY；MySQL 8.0 更激进，仍建议显式加ALGORITHM=INPLACE, LOCK=NONE - 务必先在从库或影子库上跑一遍，确认没业务报错——比如应用层用
DUPLICATE KEY异常做逻辑分支，删掉唯一索引后会直接崩
索引越多，优化器越容易“选花眼”
优化器不是智能推荐系统，它靠成本估算从所有可用索引里挑一个“看起来最快”的。索引一多，它不光要读统计信息、预估行数、比对深度，这个评估过程本身就有开销，还容易误判。
-
EXPLAIN显示type: ALL或key: NULL，别急着加新索引，先检查是否违反最左前缀（比如联合索引(a,b,c)，却查WHERE b = ?） - 已有联合索引
(user_id, status)，再单独建idx_user_id，后者大概率被忽略——优化器知道前者能覆盖单列查询 - 统计信息过期（比如大表刚导入千万行但没
ANALYZE TABLE）会导致优化器低估/高估索引效率，选错索引
EXPLAIN 输出明显劣化？这些没法靠直觉，只能靠日志、统计和压测。 
