N+1问题

在后端开发中，导致 API 性能灾难性降低的最常见错误之一是臭名昭著的“N + 1 查询”问题。

对于使用“ORM”（对象关系映射器：例如 Prisma 或 Sequelize）等库抽象从 Node.js 与数据库对话的开发人员来说，它通常是未知的。

灾难剖析

想象一个应用程序想要返回整个电子商务主页列表：所有产品以及每个产品所属的类别名称字符串。 从 Node.js 方面来看，没有经验的程序员会编写迭代循环：

1. products = await db.query("SELECT * FROM products"); （一项大而笨重的操作1）
2. 开发人员对找到的 100 个数组中的每个 product 进行迭代 (for..of)
3. 在 Node.js 中的每一步中，它们都会等待迭代子查询 categoryName = await db.query("SELECT name FROM categories WHERE id = " + product.category_id); 并将其嵌入到结果中（N 次缓慢、微小查询的二次迭代！）

对 Postgres 守护进程的请求总数： 1 + 100 次本地迭代 = 101 Node.js 和数据库之间的微网络往返。 101 次往返会导致可怕的网络开销和糟糕的延迟。在实际规模下，N 可能不是 100，而是 10,000 行待探索的发票总数！ API 在达到 5xx 超时之前不会返回。

真正的本机答案：在单个查询中加入或聚合

熟练地使用手工编写的 DBMS 抽象，而不是 Node 中的琐碎 ORM 命令，在一个无与伦比的查询中以毫秒的速度将执行融合在一起，解决了“N+1”的混乱：

SELECT
  p.id,
  p.name,
  c.name AS category_name
FROM products p
JOIN categories c ON p.category_id = c.id;

API/DB 往返总数： 1 个唯一查询，由 Postgres 自己的索引融合、数学优化，完全以 0 毫秒的额外网络延迟处理。

JSON 聚合替代方案

现代 Postgres 版本甚至允许您使用 json_agg 返回嵌套为 JSON 的整个复杂连接，从而允许您的 JavaScript 接收 products 数组，包括其格式化评论的子数组，而无需任何本地脚本粘合！ （在高级路径和挑战中，您将学习 Postgres 的 JSONb 子句。）

轮到你了

探索 GROUP BY 效率