应避免SELECT *，明确指定字段以减少传输开销、利用覆盖索引；合理设计复合索引匹配WHERE/ORDER BY/GROUP BY；慎用非SARGable条件；控制JOIN数量并选择合适驱动表。
避免 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。
