新手该不该一上来就学索引优化？
不该，但也不能完全跳过——索引是 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 真正慢、为什么慢”有真实手感的基础上。
