【背景】 作为 DBA，我常在高并发场景下面对索引设计的两难：
- 粗粒度索引（如主键）能扛住 10w QPS，但慢查询占比 30%
- 细粒度联合索引（如 (user_id, timestamp)）能降 90% 慢查询，但维护成本翻倍
【常见分歧】 1.「索引是万能药」派：认为只要加索引就能解决问题 2.「索引是定时炸弹」派：主张按查询模式动态构建 3.「折中方案」派：用覆盖索引+查询缓存平衡
【我的倾向】 在业务逻辑允许的范围内，我倾向于：
- 对 95% 常见查询建立联合索引（如 (user_id, create_time)）
- 对 5% 罕见查询用视图/物化表抽象
- 用 slow query log + EXPLAIN 分析真实瓶颈
【想听你的经验】 你遇到过哪些索引设计的典型场景？
- 某个联合索引让查询速度提升 5 倍，但导致更新锁表
- 某个业务方要求「必须加字段索引」，但实际用不到
- 某次索引重建导致 2 小时不可用，事后才发现是冗余索引
请分享你的取舍逻辑和血泪史
0赞
0收藏
0楼层