加索引导致INSERT变慢是因为MySQL需同步更新所有索引，引发B+树插入、页分裂及回表路径维护，索引越多开销越大。
为什么加了索引，INSERT反而卡住了
因为 MySQL 在写入时必须同步更新所有相关索引。每多一个索引，INSERT 就得多做一次 B+ 树插入、可能触发页分裂、还要维护二级索引的聚簇索引回表路径。尤其当表有 5 个以上二级索引，单行 INSERT 的开销可能翻 3 倍以上。
常见错误现象：SHOW PROCESSLIST 看到大量 update 或 insert 状态卡在 updating；慢查询日志里 INSERT 出现在 top 10；监控显示 Innodb_row_lock_waits 明显上升。
- 不是所有字段都值得建索引——先看
WHERE和JOIN条件里真正高频出现的组合 - 联合索引要按「等值查询字段 + 范围查询字段 + 排序字段」顺序排列，避免冗余单列索引
-
TEXT/VARCHAR(2000)类型字段不要直接建全文索引以外的索引，考虑前缀索引（如INDEX idx_name (name(16))） - 删除长期不用的索引：用
sys.schema_unused_indexes视图或performance_schema.table_io_waits_summary_by_index_usage检查
INSERT ... SELECT 场景下索引怎么取舍
批量导入数据时，索引对写入性能的影响被放大。MySQL 会为每一行新记录更新全部索引，而 INSERT ... SELECT 又常涉及大结果集扫描，容易形成双重压力。
典型场景：定时从日志表归档数据到历史表、ETL 同步、报表宽表构建。
- 执行前临时禁用非必要索引：
ALTER TABLE tbl DROP INDEX idx_unneeded，导入完成再重建 - 如果目标表只有主键，可先
CREATE TABLE ... LIKE复制结构，再DROP PRIMARY KEY+ADD PRIMARY KEY延后建主键（仅限 MyISAM 不适用，InnoDB 下需谨慎） - 控制批量大小：用
LIMIT分批INSERT ... SELECT，避免长事务和锁升级；5k~10k 行/批较稳妥 - 确认
innodb_buffer_pool_size足够，否则索引页频繁刷盘会拖垮吞吐
异步写索引：绕不开但不能瞎搞
真正的“异步建索引” MySQL 不支持，所谓异步其实是把索引维护逻辑从写入路径中剥离，靠应用层或中间件补偿。这不是银弹，而是权衡一致性与性能后的妥协方案。
适用前提：业务能接受几秒到几分钟的索引延迟生效，且查询端有兜底（比如先查主键再内存过滤）。
- 用消息队列（如 Kafka/RocketMQ）解耦写操作：应用写主表成功后发消息，消费者异步补全搜索字段或生成倒排索引表
- 避免在触发器里做复杂逻辑：
AFTER INSERT触发器调用存储过程更新另一张索引表，极易造成锁等待和死锁 - 如果用 Elasticsearch 做查询加速，不要用
logstash-jdbc实时拉取，改用 binlog 解析（如 canal/debezium），延迟更低、压力更可控 - 注意双写一致性：异步流程失败时要有重试 + 对账机制，比如定期比对
COUNT(*)和 ES 文档数
innodb_flush_log_at_trx_commit 和 sync_binlog 怎么调
这两个配置不解决索引本身的问题，但在高并发写入场景下，它们和索引共同构成 I/O 瓶颈。调得过严，INSERT 变慢；调得太松，掉电丢数据。
关键不是“要不要关”，而是“在哪关、关多久”。线上库绝不建议设为 0，但某些写多读少的分析型子库可以折中。
-
innodb_flush_log_at_trx_commit = 2：日志写 OS cache 而不刷盘，崩溃最多丢 1 秒事务，多数业务可接受 -
sync_binlog = 0或sync_binlog = 1000：避免每次事务都刷 binlog 文件，但主从延时会上升，GTID 复制下需评估位点跳跃风险 - 务必配合
innodb_io_capacity和磁盘实际 IOPS 设置，SSD 上可设为 2000，机械盘别超 200 - 调整后用
sysbench --test=oltp_insert对比 QPS 和平均延迟，别只看峰值
索引不是越全越好，也不是越快删越好。最麻烦的永远是那个“查得少但老板说将来可能要用”的字段——它往往最后变成慢查询的根因，又没人敢动。留着占空间，删了怕背锅，这才是真实处境。
