哪些字段适合加索引？别再乱建了
很多人一发现查询慢，第一反应就是“加个索引试试”。结果系统跑了一阵子，写入变慢、磁盘暴涨，才发现索引建错了地方。数据库索引不是越多越好，选对业务字段才是关键。
高频查询的 WHERE 条件字段优先
比如你做电商系统，订单列表最常按用户 ID 查。这种场景下 user_id 就是典型的索引候选字段。每次执行类似下面的语句，有索引和没索引的性能差十倍都不止：
SELECT * FROM orders WHERE user_id = 12345;相反，如果某个字段几乎不在 WHERE 中出现，就算它数据量大，也不该盲目加索引。
联合索引注意顺序：最左匹配原则不能忘
经常有人给 status 和 create_time 都加单独索引，其实不如建一个联合索引。但顺序很重要——如果你的查询是这样：
SELECT * FROM articles WHERE status = 1 AND create_time > '2024-01-01';那应该建 (status, create_time) 的联合索引。因为大多数数据库遵循最左匹配，先按 status 排，再按时间排，查起来才快。反过来 (create_time, status) 效果就差很多，特别是当 createTime 范围太大时。
避免在低区分度字段上建索引
什么叫低区分度？比如“性别”字段，只有男、女两个值。即使你建了索引，查的时候还是要扫一半数据，数据库干脆直接全表扫描得了。这种字段加索引不仅没用，还拖累写入速度。
再比如订单状态，如果大部分都是“已完成”，只有一小部分“待支付”，那 status 字段能不能建索引就得看具体查询场景。如果是查“待支付”的订单，反而能受益于索引，因为数据少、筛选效率高。
频繁更新的字段慎建索引
索引本质是额外的数据结构，每次 INSERT、UPDATE、DELETE 都要同步维护。像“浏览次数”这种动不动就 ++ 的字段，每改一次就要调整 B+ 树，IO 成本很高。这类字段即使常用于查询，也建议考虑缓存替代，而不是靠数据库硬扛。
覆盖索引能省不少事
有时候你只需要查几个字段，比如查用户昵称和头像：
SELECT nickname, avatar FROM users WHERE mobile = '13800138000';这时候如果建一个 (mobile, nickname, avatar) 的联合索引，数据库根本不用回表，直接从索引里把数据拿走就行。这就是覆盖索引的好处——减少随机 IO，提升响应速度。
业务增长带来的变化也要考虑
刚开始用户少，按用户名 username 查询没问题。但用户到了百万级，username 检索越来越慢，这时候就得重新评估是否要加索引，或者改成唯一索引 + 缓存方案。别忘了，索引策略不是一锤子买卖，得跟着业务节奏调。
还有一个常见误区：主键自动有索引，所以不用管。但如果你经常用业务编号（比如订单号）查询，还是得单独给 order_no 加唯一索引，不然全表扫下来，用户体验立马崩。