避免 SELECT *，明确指定需要的字段
全字段查询不仅增加网络传输开销，还会让 MySQL 无法有效利用覆盖索引，甚至触发临时表或文件排序。尤其在大表或高并发场景下，
SELECT *往往是慢查询的起点。 用
EXPLAIN查看执行计划时，若
Extra列出现
Using temporary或
Using filesort，大概率和冗余字段有关 联合索引中，如果
SELECT的字段未全部落在索引列上，MySQL 可能放弃使用该索引的“覆盖”能力 ORM 自动生成的
SELECT *（如 Django 的
.all()、SQLAlchemy 的
query.all()）需主动改写为只取必要字段
合理使用索引：区分 WHERE、ORDER BY 和 GROUP BY 场景
索引不是越多越好，但必须匹配实际查询模式。同一个索引能否同时服务
WHERE、
ORDER BY和
GROUP BY，取决于字段顺序和类型一致性。
WHERE a = ? AND b > ? ORDER BY c：推荐复合索引
(a, b, c)；
(a, c, b)无法用于
ORDER BY c（因为
b是范围查询，后续字段失效）
GROUP BY x, y后接
ORDER BY x, y：索引
(x, y)可同时满足，避免额外排序 对
TEXT或长
VARCHAR字段建索引需指定前缀长度，如
INDEX idx_title (title(100))，否则建索引失败或浪费空间
慎用 OR、NOT IN、LIKE 左模糊等非SARGable条件
这类写法会让 MySQL 无法使用索引进行快速定位，常导致全表扫描。即使字段有索引，也可能被优化器直接忽略。
WHERE status = 'active' OR type = 'admin'：建议拆成
UNION ALL，或改用
IN+ 多列索引（若逻辑允许）
WHERE id NOT IN (SELECT user_id FROM logs)：子查询返回
NULL会导致整个结果为空；改用
LEFT JOIN ... WHERE logs.user_id IS NULL更可靠且易走索引
WHERE name LIKE '%abc'：左模糊无法使用 B+ 树索引；如必须模糊搜索，考虑
FTS（全文索引）或引入 Elasticsearch
控制 JOIN 数量与驱动表选择
MySQL 的 JOIN 是嵌套循环（Nested Loop），驱动表（左表）的数据量直接影响整体扫描行数。小表驱动大表是基本原则，但优化器不总能选对。
用STRAIGHT_JOIN强制指定驱动表顺序，例如
SELECT STRAIGHT_JOIN ... FROM small_table t1 JOIN big_table t2 ON t1.id = t2.t1_id避免在 JOIN 条件中对字段做函数操作，如
ON DATE(t1.created_at) = DATE(t2.date)—— 这会让索引失效 超过 3 张表 JOIN 时，务必检查每张表是否有对应过滤条件（
WHERE）或连接索引，否则中间结果集可能爆炸式增长
EXPLAIN FORMAT=TREE SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' AND o.created_at > '2024-01-01';
真正影响性能的，往往不是单条语句多复杂，而是它在什么数据分布、什么并发压力、什么缓存状态下运行。索引策略要随数据倾斜度调整，
EXPLAIN要看
rows和
filtered，而不仅是
type是否为
ref或
range。
