优化 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 结构
