索引需权衡读写性能，应依真实压力分布、查询模式及字段使用频率精准设计。优先保障高频查询，收敛冗余索引，用前缀索引与延迟更新缓解写入压力，并善用聚簇索引特性避免随机主键。
索引能加速查询，但会拖慢写入——这是 MySQL 性能调优中最典型的取舍场景。关键不是“要不要加索引”，而是“为哪些字段、在什么查询模式下、加什么样的索引”。
明确写入与查询的真实压力分布
很多团队默认“读多写少”，但实际业务中常有反例：日志归档、实时埋点、IoT 设备上报等场景，写入 QPS 远超查询。先用 SHOW GLOBAL STATUS LIKE 'Com_insert%' 和 Com_select% 对比增量，再结合 slow query log 看慢查询是否真集中在高频写入表上。如果某张表 90% 的操作是 INSERT/UPDATE，却堆了 5 个二级索引，那索引就是主要瓶颈。
优先保障高频查询路径，收敛低效索引
一个字段被 WHERE、ORDER BY、GROUP BY 多次用到，才值得建索引；重复覆盖的索引（如已有 (a,b)，又单独建 (a)）要合并；前缀过长的 VARCHAR 索引（如 VARCHAR(255) 全长索引）改用前缀索引（INDEX(a(12))），既保区分度又省空间。用 EXPLAIN FORMAT=JSON 查看 key_len 和 used_key_parts，确认索引是否被真正用上。
用延迟更新或异步方式缓解写入压力
对非强实时场景（如统计报表、用户画像宽表），可把高频写入拆成两层：原始表只存 raw 数据、不建复杂索引；用定时任务（如每 5 分钟）将数据聚合写入带索引的汇总表。或者用消息队列缓冲写入，由消费者批量处理并更新索引表，避免事务内直接触碰多个索引。
合理利用主键和聚簇索引特性
InnoDB 主键即聚簇索引，数据按主键物理排序。若业务天然有序（如时间戳 ID、订单号递增），用自增主键能减少页分裂；若频繁按时间范围查，又常按用户 ID 过滤，可考虑联合主键 (user_id, create_time) 或添加合适二级索引。避免用 UUID 或随机字符串作主键——它会导致大量随机 I/O 和索引碎片，显著拉低写入吞吐。
不复杂但容易忽略。索引不是越多越好，也不是越少越快，是在具体负载、数据分布和查询模式下做动态权衡。
