InnoDB索引更新更重，因其聚簇索引设计需同步维护聚簇页、二级索引页、undo log、redo log及doublewrite buffer，而MyISAM仅更新独立索引文件且无事务开销。
InnoDB索引更新为什么比MyISAM更重？
InnoDB 的索引更新开销天然高于 MyISAM，核心原因不在“树结构”，而在事务机制和存储设计。MyISAM 是堆表 + 独立索引文件，更新时只改对应 B-Tree 叶子节点；InnoDB 是聚簇索引（主键即数据），所有二级索引都隐式包含主键值，每次 INSERT/UPDATE/DELETE 都要同步维护：聚簇索引页、所有涉及的二级索引页、undo log、redo log、doublewrite buffer —— 这些全是额外 I/O 和锁竞争点。
-
INSERT一条记录：InnoDB 至少触发 1 次聚簇索引页写入 + N 次二级索引页写入 + redo log 刷盘（取决于innodb_flush_log_at_trx_commit） -
UPDATE主键字段：相当于删旧行 + 插新行 → 所有索引全量重建，页分裂风险陡增 -
UPDATE二级索引列（如status）：该列所在的所有二级索引都要定位、修改、可能分裂；若该列选择性低（如只有 3 个取值），更新频次越高，维护代价越不成比例
MyISAM 索引看似轻量，但不能照搬它的思路
MyISAM 的 .MYI 文件是纯 B-Tree 结构，不参与事务，也不保证崩溃恢复，所以更新快——但这恰恰是它在现代业务中基本被淘汰的原因。你看到的“低维护成本”，是以牺牲 ACID、并发安全、崩溃一致性为代价换来的。
- MyISAM 表级锁 → 高并发
UPDATE下，一个慢查询就能堵死整张表 - 无事务日志 → 崩溃后只能靠
REPAIR TABLE，且大概率丢数据 - 二级索引不存主键 → 查询必须回表到
.MYD，而 InnoDB 的聚簇特性让主键查询零回表，二级索引回表也更局部化
所以别被“MyISAM 更新快”误导；真正该对比的，是 InnoDB 下不同索引设计对写性能的实际影响。
如何用 SHOW ENGINE INNODB STATUS 看出索引更新瓶颈？
这不是看“有没有锁”，而是盯住 SEMAPHORES 和 TRANSACTIONS 区域里与索引操作强相关的信号：
- 若
OS WAIT ARRAY INFO中大量线程卡在dict0dict.cc或btr0cur.cc，说明正在争抢索引字典锁或 B-Tree latch - 在
TRANSACTIONS列表里看到很多事务状态为inserting或updating index，且lock struct(s)数量高，大概率是某二级索引成了热点 - 配合
SELECT * FROM performance_schema.table_io_waits_summary_by_table查WRITE次数最高的表，再查其INDEX_LENGTH / DATA_LENGTH比值 —— 若 > 1.5，说明索引体积已严重超标
真正能降本的实操动作，就这三类
优化不是“删索引”，而是把索引从“被动响应”变成“主动收敛”。重点不是减少数量，而是压缩无效变更面。
- 把高频更新列（如
updated_at、status）从二级索引首位移走；如果必须查，优先用覆盖索引，比如KEY idx_status_type (status, type, id)而非KEY idx_status (status) - 用前缀索引替代完整字符串索引：
VARCHAR(255)字段建索引时，先用SELECT COUNT(DISTINCT LEFT(col, 10)) / COUNT(*)测区分度，够用就用KEY idx_name (name(10)) - 冷数据归档后，立刻
DROP INDEX—— 不要留着“以防万一”；归档表本身就不该承担在线查询压力，索引只会拖慢INSERT INTO ... SELECT迁移过程
最常被忽略的一点：索引维护成本不是静态值，它随数据分布动态恶化。比如 UUID 主键导致的随机插入，半年后页分裂率可能从 5% 升到 40%，但监控里只显示“写入延迟上升”，没人去翻 INFORMATION_SCHEMA.INNODB_METRICS 里的 index_page_splits。这种退化，得靠定期采样分析，而不是等告警。
