那些年我们忽视的 SQL 错误，及如何写出高效易维护代码

Jacob0234
110 阅读6分钟

SQL 看似简单，语法也不复杂，但它是一门深刻且微妙的语言。即使是多年经验的开发者，也经常犯一些容易忽视的错误，导致性能问题、维护难度增加，甚至数据错误。

以下为九个常见的 SQL 使用误区：

1. 盲目使用 SELECT * ：便利背后的陷阱

许多开发者习惯用 SELECT * 快速拿到所有字段，尤其在调试阶段。但在生产环境，这种用法弊端显著：

  • 拉取无用数据，增加网络负载和 I/O 压力
  • 查询优化受阻，数据库难以跳过不必要的字段
  • 表结构变更时导致意外错误或数据变动

示例：

-- 不建议的写法
SELECT * FROM users WHERE status = 'active';

-- 推荐写法
SELECT id, username, email FROM users WHERE status = 'active';

为避免误用，团队应引入代码审查工具或 SQL Linter，自动检测并提示 SELECT *。

2. 索引设计误区：缺失、滥用与过度

索引是数据库性能优化的关键，但常见误区包括：

  • 缺少必要索引，导致全表扫描，查询缓慢
  • 错误索引，影响写入性能
  • 过多索引，造成存储膨胀与更新阻塞

示例：

假设有以下查询：

SELECT * FROM orders WHERE customer_id = 1234 ORDER BY order_date DESC LIMIT 10;

如果 customer_id 没有索引，数据库必须扫描全表。

优化示例：

-- 创建合适索引
CREATE INDEX idx_orders_customer_date ON orders(customer_id, order_date DESC);

执行计划工具 EXPLAIN 能帮助判断索引是否生效。

3. 小数据测试误区：性能不会线性扩展

在小数据集上测试没问题的查询，到了大规模数据环境，可能变成性能灾难。

示例：

WITH recent_orders AS (
  SELECT * FROM orders WHERE order_date > CURRENT_DATE - INTERVAL '30 days'
)
SELECT customer_id, COUNT(*) FROM recent_orders GROUP BY customer_id;

在只有几百条记录时运行流畅，但生产中几百万条会导致查询缓慢。

建议：

  • 始终在接近生产环境的数据规模上测试
  • 使用分页（LIMIT/OFFSET）减小单次查询量
  • 监控慢查询日志，定期优化

4. 连接（JOIN）条件错误：隐形性能杀手

忘记写 ON 条件会产生笛卡尔积，令结果集激增，耗尽资源。

错误示例：

SELECT * FROM orders JOIN customers;
-- 没有 ON 条件，所有订单和所有客户两两配对，结果集暴增

正确示例：

SELECT o.id, c.name FROM orders o
JOIN customers c ON o.customer_id = c.id;

务必确认每个 JOIN 都有清晰的条件，避免结果膨胀。

5. 过度依赖子查询：写法简单但效率低

子查询有时会重复扫描表，降低性能。

低效示例：

SELECT name FROM users WHERE id IN (
  SELECT user_id FROM purchases WHERE amount > 100
);

数据库可能为每个 users 行执行子查询，导致性能瓶颈。

优化示例：

SELECT u.name FROM users u
JOIN purchases p ON u.id = p.user_id
WHERE p.amount > 100;

更进一步，可以用 CTE 使查询更清晰：

WITH big_purchases AS (
  SELECT DISTINCT user_id FROM purchases WHERE amount > 100
)
SELECT u.name FROM users u
JOIN big_purchases bp ON u.id = bp.user_id;

6. 忽视集合思维：避免用游标和循环

SQL 是声明式集合语言，逐行处理（游标、循环）不仅效率低，而且复杂。

反例：

用游标逐行处理用户：

DECLARE user_cursor CURSOR FOR SELECT id FROM users;
OPEN user_cursor;
FETCH NEXT FROM user_cursor INTO @user_id;
WHILE @@FETCH_STATUS = 0
BEGIN
  -- 逐行操作，性能差，代码复杂
  FETCH NEXT FROM user_cursor INTO @user_id;
END
CLOSE user_cursor;
DEALLOCATE user_cursor;

推荐：使用窗口函数

WITH ranked_orders AS (
  SELECT user_id, order_id,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) AS rn
  FROM orders
)
SELECT * FROM ranked_orders WHERE rn = 1;

高效简洁，充分利用 SQL 集合特性。

7. 忽略事务和隔离级别：数据一致性风险

多步骤操作不包裹事务，会出现部分成功、部分失败，数据不一致。

无事务风险示例：

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
-- 若第二条失败，资金流失

正确示例：

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

此外，理解隔离级别（READ COMMITTED、SERIALIZABLE 等）对控制并发影响至关重要。

8. 不用 EXPLAIN 和分析工具：盲目调优

不查看执行计划，就像盲人摸象，调优效果有限。

使用 EXPLAIN 可见查询是否用索引，是否全表扫描：

EXPLAIN SELECT * FROM orders WHERE customer_id = 1234;

查看执行计划，定位瓶颈，结合慢查询日志监控，持续优化。

同时推荐本地测试工具 ServBay：

  • 轻松启动多版本数据库实例
  • 支持执行计划和慢查询分析
  • 本地无服务器环境，避免频繁访问生产库

9. 把 SQL 当作边缘技能：忽略代码管理和文档

SQL 往往在项目中被视作“辅助”，缺少版本控制、文档和代码审查，导致维护困难，数据错误频发。

建议：

  • 采用版本管理工具（Git）管理 SQL 脚本和数据库结构
  • 编写注释，说明查询意图和边界条件
  • 推行代码审查和单元测试，确保稳定性
  • 及时邀请数据工程师或 DBA 参与设计

同样，ServBay 支持集成版本控制，方便团队本地协作，保证SQL 代码的可维护性和可追踪性。

结语

在实际工作中，很多资深开发者也强调，CTE（公共表表达式）相较于嵌套子查询更具优势，它不仅让查询逻辑更清晰，还便于逐步调试。事务管理同样不可忽视，建议从使用 TRY/CATCH 包裹逻辑并做好错误日志记录开始，确保数据一致性和排查方便。表设计方面，数据类型是数据库的第一道约束，选择合适的数据类型至关重要，需理解背后的设计原则。此外，良好的命名规范和统一的格式化习惯，是高级开发者的基本素养，有助于代码的维护与团队协作。最后，版本控制也不能马虎，切忌随意创建诸如 _v2_final_final 之类的混乱版本号，推荐使用 Git 等专业工具管理数据库代码。

面向进阶者的建议路线

如果你已有 1–2 年 SQL 使用经验，建议重点提升以下能力：

技术方向：

  • 熟练掌握窗口函数（如 ROW_NUMBER(), LAG(), RANK()）
  • 深入了解数据库元数据表（sys.objects、INFORMATION_SCHEMA）
  • 透彻理解事务机制、锁机制与并发控制

工程化方向：

  • 学习并实践 SQL 的 CI/CD 自动化方案，如 dbt
  • 将数据库 Schema 纳入版本控制，实现架构可追踪
  • 使用 SQL Linter 和 Formatter 工具，保持代码规范与可读性
avatar
文章
阅读
粉丝