真实生产案例：一次错误索引设计如何引发 MySQL 写性能雪崩
在性能优化实践中，索引往往是第一把手术刀。但如果用错位置，它也可能成为压垮数据库的最后一根稻草。
这篇文章复盘一次真实的线上事故： 👉 一次“看似合理”的索引优化，最终导致写性能雪崩、主从延迟、接口超时。
🧨 一、事故背景
业务场景： 电商订单系统 数据库： MySQL 8.0 / InnoDB 表： orders（日增 300 万 + 高频更新）
核心字段：
CREATE TABLE orders ( id BIGINT PRIMARY KEY, user_id BIGINT, status TINYINT, amount DECIMAL(10,2), create_time DATETIME, update_time DATETIME );读写特征：
| 类型 | 特征 |
|---|---|
| INSERT | 高频（秒级上万） |
| UPDATE | 高频（状态流转） |
| SELECT | 按 user_id / status 查询 |
⚙️ 二、变更起因：一次“性能优化”
慢查询报警：