在企业级应用开发中，数据库作为数据存储与检索的核心组件，其性能直接影响系统的响应速度与稳定性。而 SQL 语句作为与数据库交互的语言，编写的优劣往往决定了查询效率的高低。本文将聚焦于导致 SQL 性能低下的常见语法问题，结合具体业务场景分析其背后的原因，并给出针对性的优化策略，最后汇总 SQL 调优相关的高频面试题，帮助开发者全面掌握这一关键技能。

一、导致 SQL 性能低下的常见语法问题及原因分析

1.1 全表扫描：未合理使用索引

场景：在电商系统中查询某个品牌的商品列表，执行以下 SQL：

SELECT * FROM products WHERE brand = 'Apple';

问题：若products表未在brand字段上创建索引，数据库将对全表进行扫描。当表中数据量较大时，查询效率会急剧下降。

原因：索引类似于书籍的目录，通过索引可以快速定位到满足条件的数据行。未创建索引时，数据库只能逐行扫描表中的每一条记录，时间复杂度为 O (n)。

优化：在brand字段上创建索引：

CREATE INDEX idx_brand ON products(brand);

优化后，数据库可通过索引快速定位到符合条件的数据，查询效率大幅提升。

1.2 索引失效：函数操作与表达式计算

场景：在日志系统中查询某段时间内的日志记录，执行以下 SQL：

SELECT * FROM logs WHERE DATE_FORMAT(log_time, '%Y-%m-%d') = '2024-01-01';

问题：对log_time字段使用了DATE_FORMAT函数，导致索引失效，数据库无法利用log_time字段上的索引进行快速查询。

原因：对索引字段进行函数操作或表达式计算，会使数据库无法直接使用索引，只能进行全表扫描。因为数据库需要对每一行数据执行函数或表达式后再进行条件匹配。

优化：将函数操作移到条件的另一侧：

SELECT * FROM logs WHERE log_time >= '2024-01-01 00:00:00' AND log_time < '2024-01-02 00:00:00';

若必须使用函数，可创建基于函数的索引（不同数据库实现方式略有差异）。

1.3 关联查询：不合理的 JOIN 条件与驱动表选择

场景：在订单系统中查询订单及其对应的用户信息，执行以下 SQL：

SELECT * FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.order_date >= '2024-01-01';

问题：若orders表数据量较大，users表数据量较小，且未在关联字段user_id和id上创建索引，查询性能会很差。此外，若驱动表选择不当，也会影响性能。

原因：关联查询时，数据库需要将两个表的数据进行匹配，若没有索引支持，会进行大量的嵌套循环操作。驱动表的选择会影响循环的顺序，若选择数据量大的表作为驱动表，会导致更多的循环次数。

优化：在user_id和id字段上创建索引：

CREATE INDEX idx_user_id ON orders(user_id);
CREATE INDEX idx_id ON users(id);

同时，根据表的大小合理选择驱动表，一般选择数据量小的表作为驱动表。在 MySQL 中，可使用STRAIGHT_JOIN强制指定驱动表顺序：

SELECT * FROM users u
STRAIGHT_JOIN orders o ON o.user_id = u.id
WHERE o.order_date >= '2024-01-01';

1.4 子查询：过多嵌套与低效使用

场景：在员工管理系统中查询工资高于部门平均工资的员工，执行以下 SQL：

SELECT * FROM employees e
WHERE e.salary > (
    SELECT AVG(salary) FROM employees WHERE department_id = e.department_id
);

问题：子查询会为外部查询的每一行数据都执行一次，当数据量较大时，性能损耗严重。

原因：嵌套子查询会导致数据库执行多次查询，每次外部查询的一行数据都需要重新执行子查询，效率低下。

优化：使用关联查询替代子查询：

SELECT e.*
FROM employees e
JOIN (
    SELECT department_id, AVG(salary) AS avg_salary
    FROM employees
    GROUP BY department_id
) d ON e.department_id = d.department_id AND e.salary > d.avg_salary;

通过关联查询，将子查询的结果作为临时表进行关联，减少查询次数。

1.5 模糊查询：以通配符开头

场景：在商品搜索系统中查询名称包含 “手机” 的商品，执行以下 SQL：

SELECT * FROM products WHERE product_name LIKE '%手机%';

问题：当product_name字段上有索引时，以通配符开头的模糊查询会导致索引失效，进行全表扫描。

原因：以通配符开头的查询，数据库无法利用索引的有序性进行快速定位，只能逐行扫描表数据进行匹配。

优化：尽量避免以通配符开头的模糊查询，若必须使用，可考虑使用全文索引（如 MySQL 的 FULLTEXT 索引）：

CREATE FULLTEXT INDEX idx_product_name ON products(product_name);
SELECT * FROM products WHERE MATCH(product_name) AGAINST('手机' IN NATURAL LANGUAGE MODE);

二、常见 SQL 调优策略

1. 合理创建索引：根据查询条件，在经常用于WHERE、JOIN、ORDER BY的字段上创建索引，但索引并非越多越好，过多的索引会增加数据插入、更新和删除的开销。

2. ** 避免使用 SELECT ***：只查询需要的字段，减少数据传输量和解析时间。

3. 优化 JOIN 操作：确保关联字段有索引，合理选择驱动表和关联方式（如 INNER JOIN、LEFT JOIN 等）。

4. 减少子查询嵌套：能用关联查询替代的尽量替代，提高查询效率。

5. 使用存储过程和视图：将复杂的查询逻辑封装在存储过程中，减少应用层与数据库的交互次数；使用视图简化复杂的查询语句，提高可读性和维护性。
6. 定期分析和优化表结构：对表进行ANALYZE TABLE（MySQL）或ANALYZE（Oracle）操作，让数据库统计信息更准确，有助于优化器生成更优的执行计划；根据业务需求调整表结构，如拆分大表等。

三、SQL 调优高频面试题

1. 问题：索引失效的常见场景有哪些？回答：对索引字段进行函数操作或表达式计算；使用以通配符开头的模糊查询；联合索引未满足最左前缀原则；数据类型不匹配（如字段为VARCHAR，查询时传入NUMBER类型且未自动转换）等。
2. 问题：如何优化慢 SQL？回答：首先通过数据库的执行计划分析工具（如 MySQL 的EXPLAIN、Oracle 的EXPLAIN PLAN）查看 SQL 的执行计划，找出性能瓶颈；然后根据具体问题进行优化，如创建或优化索引、调整关联查询方式、避免子查询嵌套、优化分组和排序操作等；最后进行性能测试，验证优化效果。
3. 问题：LEFT JOIN 和 INNER JOIN 的区别是什么？在性能上有什么差异？回答：LEFT JOIN返回左表的所有行以及右表中匹配的行，若右表无匹配行，则用NULL填充；INNER JOIN只返回两个表中满足连接条件的行。性能上，一般情况下INNER JOIN效率更高，因为它无需处理NULL值，且数据量相对较少；但具体性能还取决于表的大小、索引情况以及数据分布等因素。
4. 问题：什么是覆盖索引？它对 SQL 性能有什么影响？回答：覆盖索引是指查询所需的所有列都包含在索引中，此时数据库无需回表查询（即无需再访问表数据），直接从索引中获取数据，大大提高了查询效率。使用覆盖索引可以减少 I/O 操作，降低查询响应时间。
5. 问题：在 MySQL 中，如何查询执行最慢的 SQL 语句？回答：可以通过开启慢查询日志（修改my.cnf配置文件，设置slow_query_log = 1，并指定日志文件路径），MySQL 会将执行时间超过阈值（long_query_time参数，默认 10 秒）的 SQL 语句记录到日志文件中，通过分析日志文件即可找到执行最慢的 SQL。也可以使用SHOW PROCESSLIST命令查看当前正在执行的 SQL 及其执行状态。