应避免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 无法使用索引进行快速定位，常导致全表扫描。即使字段有索引，也可能被优化器直接忽略。
