🔧 MySQL 索引的设计原则有哪些？【原理 + 业务场景实战】
在数据库优化中，索引设计的好坏 直接决定了系统性能的上限。很多项目一上线压力就飙升，慢查询频出，本质上是 ------ 索引没设计好！
本文将从 MySQL 索引的设计原则 出发，结合多个典型业务场景，逐条讲解如何设计出高效、合理、易维护的索引。
🧱 一、为什么要设计索引？
索引的作用是加速查询、减少磁盘 I/O。设计索引的核心目标是：
- 提高查询效率
- 控制写入/更新成本
- 避免冗余索引
- 提升系统整体性能
📐 二、常见索引设计原则总览
| 编号 | 原则 | 是否关键 | 说明 |
|---|---|---|---|
| 1 | 选择区分度高的列建立索引 | ✅ 关键 | 提高过滤效率 |
| 2 | 使用联合索引，遵循最左前缀原则 | ✅ 关键 | 多列查询中的利器 |
| 3 | 覆盖索引，避免回表 | ✅ 高效 | 提升查询速度 |
| 4 | 控制索引数量，避免过度索引 | ✅ 性能 | 索引并非越多越好 |
| 5 | 更新频繁的字段慎用索引 | ⚠️ 性能 | 写入代价大 |
| 6 | LIKE 前置通配符无法使用索引 | ⚠️ 陷阱 | %abc 会失效 |
| 7 | NULL 字段慎用索引 | ⚠️ 可选 | 可能导致索引失效 |
| 8 | 用索引支持排序和分组 | ✅ 提升 | 减少排序开销 |
🧠 三、结合业务场景详细说明
✅ 原则一：选择区分度高的列建立索引
定义： 区分度 = 唯一值数量 / 总记录数
越接近 1，效果越好。
❌ 错误示例：
sql
-- 在性别字段建立索引
CREATE INDEX idx_gender ON user(gender);问题：只有两个值（男/女），选择性太低，过滤能力差，可能导致全表扫描。
✅ 正确示例：
sql
-- 在手机号字段建立索引
CREATE INDEX idx_phone ON user(phone);场景： 登录验证、找回密码、唯一用户识别
sql
SELECT * FROM user WHERE phone = '13888888888';✅ 原则二：使用联合索引，遵循最左前缀原则
✅ 正确设计：
scss
CREATE INDEX idx_status_create_time ON order(status, create_time);可支持的查询：
sql
-- 匹配到 status
SELECT * FROM order WHERE status = 'PAID';
-- 匹配到 status + create_time
SELECT * FROM order WHERE status = 'PAID' AND create_time > '2023-01-01';❌ 错误示例：
sql
-- 忽略最左列，索引失效
SELECT * FROM order WHERE create_time > '2023-01-01';原因：最左前缀原则未命中
status，导致无法使用索引。
✅ 原则三：使用覆盖索引减少回表
定义： 查询的字段全部在索引中，InnoDB 可直接从索引中返回结果，无需回表。
✅ 场景举例：用户只查用户名和手机号
scss
CREATE INDEX idx_user_simple ON user(username, phone);
sql
SELECT username, phone FROM user WHERE username = 'Tom';因为查询字段都在索引中，InnoDB 不必回表，提高查询效率。
❌ 原则四：控制索引数量，避免过度索引
❌ 错误示例：
有些开发者把每个字段都建了索引：
scss
CREATE INDEX idx_email ON user(email);
CREATE INDEX idx_phone ON user(phone);
CREATE INDEX idx_username ON user(username);问题：
- 写入时，每条记录都要更新多个索引，降低写入性能
- 索引占用磁盘空间
- 查询优化器难以选择最优索引
✅ 建议：
- 分析查询频率高的字段建索引
- 尽量合并为联合索引
- 使用慢查询日志 +
EXPLAIN进行优化
⚠️ 原则五：更新频繁的字段慎用索引
背景： 每次 INSERT/UPDATE/DELETE 都要维护索引树，频繁更新字段会让索引成为负担。
❌ 错误示例：
scss
CREATE INDEX idx_login_time ON user(last_login_time);问题：登录频繁更新，索引维护代价高，影响写入性能。
✅ 优化建议：
- 可用定时任务异步批量更新
- 或将活跃度高的字段缓存到 Redis
⚠️ 原则六：LIKE 前置通配符无法使用索引
❌ 错误示例：
sql
SELECT * FROM product WHERE name LIKE '%手机';问题：前置
%无法使用 B+Tree 索引，只能全表扫描
✅ 正确方式：
sql
SELECT * FROM product WHERE name LIKE '手机%';或者使用 全文索引：
sql
ALTER TABLE product ADD FULLTEXT(name);
SELECT * FROM product WHERE MATCH(name) AGAINST('手机');⚠️ 原则七：NULL 字段慎用索引
MySQL 对含 NULL 的字段索引支持有限，某些情况下会导致索引不被使用。
❌ 错误示例：
sql
SELECT * FROM user WHERE deleted_at IS NULL;可能不会使用 deleted_at 的索引。
✅ 建议：
- 使用默认值（如
deleted = 0）代替 NULL - 或增加
NOT NULL限制
✅ 原则八：用索引支持排序和分组
✅ 场景：按时间排序分页
sql
SELECT * FROM article WHERE status = 'PUBLISHED' ORDER BY publish_time DESC LIMIT 20;推荐索引：
sql
CREATE INDEX idx_status_time ON article(status, publish_time DESC);排序字段也出现在索引中，避免排序操作，性能更高。
✅ 总结：索引设计八大原则对照表
| 原则编号 | 原则描述 | 是否推荐 | 示例场景 |
|---|---|---|---|
| 1 | 区分度高的列建索引 | ✅ 强烈推荐 | 手机号、身份证号、ID |
| 2 | 联合索引 + 最左前缀 | ✅ 强烈推荐 | 订单状态 + 时间组合查询 |
| 3 | 覆盖索引优化查询 | ✅ 推荐 | 查询字段都在索引中 |
| 4 | 控制索引数量，避免冗余 | ✅ 推荐 | 慢查询分析后再建索引 |
| 5 | 更新频繁字段慎用索引 | ⚠️ 谨慎使用 | 登录时间、活跃度字段 |
| 6 | LIKE 前缀匹配使用索引 | ✅ 推荐 | LIKE 'abc%' 可用索引 |
| 7 | NULL 字段慎用索引 | ⚠️ 注意 | 使用默认值或 NOT NULL 限制 |
| 8 | 排序分页字段建索引 | ✅ 推荐 | 时间排序、ID 排序 |
📌 写在最后
索引设计是一门 技术+经验+业务理解 的综合能力。切记：
不是所有字段都要建索引，而是哪些字段"值得"建索引。
每加一个索引，都是对查询速度的投资，也是对写入性能的成本。权衡、分析、测试 是打造高性能系统的必经之路。
如果你觉得本文对你有帮助，欢迎点赞、收藏、转发！
也欢迎在评论区留言，分享你的索引优化经验 👇