优化mysql sql语句的核心是减少扫描行数、避免临时表和文件排序、充分利用索引、降低锁等待及资源压力；需遵循最左前缀原则建复合索引，禁用索引列上的函数与隐式转换，善用EXPLaiN分析执行计划，精简查询字段与结果集，合理设计JOIN顺序与条件，规避OR、深分页、大字段模糊查询等性能陷阱。
优化 MySQL SQL 语句的核心是让查询更快、更省资源，关键在于减少扫描行数、避免临时表和文件排序、充分利用索引，并降低锁等待和 CPU/内存压力。
用好索引，避免全表扫描
绝大多数慢查询源于没走索引或索引失效。确保 WHERE、JOIN、ORDER BY、GROUP BY 中涉及的字段有合适索引：
- 复合索引注意最左前缀原则，例如 INDEX (a, b, c) 能加速
WHERE a=1 AND b=2，但对WHERE b=2无效 - 避免在索引列上做函数操作或隐式类型转换，如
WHERE YEAR(create_time) = 2024或WHERE mobile = 13800138000（mobile 是字符串类型）会导致索引失效 - 用 EXPLAIN 查看执行计划，重点关注 type（尽量为 ref/const，避免 ALL）、rows（扫描行数越少越好）、key（是否命中索引）、Extra（避免 using filesort / Using temporary）
精简查询逻辑，只取真正需要的数据
少查、少算、少传，从源头降低开销：
- 禁止无条件
select *，明确列出所需字段，尤其避免大字段（TEXT/BLOB）被频繁读取 - 用 LIMIT 限制结果集大小，分页时避免
LIMIT 1000000, 20这类深分页，可改用游标方式（如WHERE id > last_id ORDER BY id LIMIT 20） - 聚合计算尽量下推到数据库，但避免在大表上滥用子查询或多重嵌套；能用 JOIN 的别用多次单表查询
- 区分 count(*) 和 COUNT(列)，前者统计行数（InnoDB 会优化），后者需判空，性能略低
合理设计 JOIN 和 WHERE 条件
多表关联容易放大数据量和计算成本，需谨慎控制驱动顺序和过滤时机：
- 小表驱动大表：把数据量小、过滤性强的表放在 JOIN 左侧（MySQL 通常按 FROM 顺序选择驱动表，但优化器可能调整）
- JOIN 字段类型和字符集必须严格一致，否则无法走索引
- WHERE 条件中尽早过滤，把高区分度条件（如 status=1 AND is_deleted=0）放在前面，减少中间结果集
- 避免在 JOIN ON 条件里写复杂表达式，如
ON a.id = b.parent_id + 1通常无法使用索引
规避常见性能陷阱
有些写法看似简洁，实则代价高昂：
- 慎用 OR：多个 OR 条件常导致索引失效，可尝试改写为 union（注意去重开销）或使用 IN（前提是字段类型一致且值不多）
- 避免在大字段上做 LIKE 模糊查询：
LIKE '%abc'无法用索引；LIKE 'abc%'可以，必要时考虑全文索引或倒排表 - UPDATE/DELETE 带非索引 WHERE 条件会锁全表或大量行，务必先确认执行计划
- 临时表和文件排序（Using temporary / Using filesort）消耗内存和磁盘 I/O，可通过添加覆盖索引或调整 sort_buffer_size 缓解，但根本还是优化 SQL 结构