不该，但也不能完全跳过——索引是mysql里“最早会痛、也最容易见效”的环节；新手应从主键索引认知、explain识别全表扫描、show index查看索引结构起步，按三步实操路径渐进掌握。
新手该不该一上来就学索引优化？
不该，但也不能完全跳过——索引是 MySQL 里「最早会痛、也最容易见效」的环节。你写完第一个 SELECT * FROM users WHERE email = 'a@b.com' 却发现查 10 万行要 2 秒，这时候不学索引，就只能干等。
真正适合新手的起点不是“怎么建复合索引”，而是：
- 知道主键自动带索引，
WHERE id = ?快是理所当然的 - 看到
EXPLAIN输出里type: ALL就明白这是全表扫描，得想办法改 - 能用
SHOW INDEX FROM table_name看出有没有索引、字段顺序是什么
从零开始的实操路径：三步踩实
别按文档章节学，按你手里的 SQL 痛点推进：
-
第 1 步（建表后立刻做）：给所有
WHERE、JOIN ON、ORDER BY里出现的字段，单独加普通索引。比如user_id和status都常被过滤，就分别建INDEX idx_user_id (user_id)和INDEX idx_status (status) -
第 2 步（慢查询出现时）：用
EXPLAIN看执行计划，如果发现两个条件一起用（如WHERE user_id = 1 AND status = 2）却只走了一个索引，就合并成复合索引：INDEX idx_user_status (user_id, status)——注意顺序：等值查询字段放前，范围/排序字段放后 -
第 3 步（数据量破 10 万后）：检查
SELECT返回的字段是否都在索引里。比如索引是(user_id, name, age)，而你只查SELECT name, age FROM users WHERE user_id = 1，这就是覆盖索引，不用回表，快得多
新手最常踩的三个坑
这些不是“理论错误”，是真正在开发中导致线上查询变慢的高频操作：
-
WHERE DATE(create_time) = '2025-01-01'—— 对索引列用函数，直接让索引失效；应改成create_time BETWEEN '2025-01-01 00:00:00' AND '2025-01-01 23:59:59' - 建了
INDEX idx_a_b_c (a,b,c)，却查WHERE b = 2 AND c = 3—— 不满足最左前缀，索引压根不用；要么调整查询逻辑，要么补一个INDEX idx_b_c (b,c) - 给
gender（只有 'M'/'F'）或is_deleted（0/1）这种低区分度字段单独建索引 —— MySQL 优化器大概率忽略它，还拖慢写入；这类字段更适合放在复合索引的末尾，而非独立存在
什么时候该停？别卷索引本身
当你能稳定做到这三点，就可以先放下索引细节，去碰更实际的问题：
- 慢查询日志里没再出现
type: ALL或rows明显大于实际结果数 - 加了索引后
INSERT/UPDATE没明显变卡（说明没滥用） - 业务 SQL 里不再出现
SELECT *、LIKE '%xxx%'这类天然难优化的写法
索引不是终点，而是你第一次看清数据流向的显微镜。后面分库分表、读写分离、缓存策略，都建立在你对“哪条 SQL 真正慢、为什么慢”有真实手感的基础上。
