如何优化 PostgreSQL 中的连接查询性能？

🍅关注博主🎗️ 带你畅游技术世界，不错过每一次成长机会！
📚领书：PostgreSQL 入门到精通.pdf

PostgreSQL

文章目录

如何优化 PostgreSQL 中的连接查询性能？
- 一、理解连接查询的基本原理
- 二、优化连接查询的关键策略
- - （一）创建合适的索引
  - （二）确保连接条件清晰准确
  - （三）合理选择连接类型
  - （四）减少数据量
- 三、实战中的优化案例
- 四、持续监控和调整

美丽的分割线

如何优化 PostgreSQL 中的连接查询性能？

在数据库的世界里，连接查询就像是一场错综复杂的舞蹈，跳得好能带来优美的结果，跳得不好就可能让整个表演陷入混乱。当我们谈到 PostgreSQL 中的连接查询性能优化时，就如同在精心打磨一件珍贵的艺术品，需要耐心、技巧和对细节的极致追求。

想象一下，你正在经营一家繁忙的超市。顾客们在各个货架之间穿梭，挑选着他们需要的商品。而数据库中的连接查询，就像是超市的仓库管理员，要快速而准确地从不同的货架（表）中找到相关的商品（数据），并将它们组合在一起供前台销售（查询结果）。如果这个管理员动作迟缓、效率低下，那么顾客可能会因为等待太久而感到不满，甚至选择去别的超市（使用其他数据库或应用）。

一、理解连接查询的基本原理

在深入优化之前，我们得先搞清楚连接查询到底是怎么回事。简单来说，连接查询就是将两个或多个表中的数据根据某种关联条件组合在一起。这就好比把拼图的各个部分拼接到一起，形成一幅完整的画面。

PostgreSQL 中常见的连接类型有内连接（INNER JOIN）、左连接（LEFT JOIN）、右连接（RIGHT JOIN）和全外连接（FULL OUTER JOIN）。每种连接类型都有其特定的用途和行为。

内连接只会返回两个表中满足连接条件的行，就像是只挑选出能完美匹配的拼图块。左连接则会返回左表中的所有行以及与右表中匹配的行，如果右表中没有匹配的行，则相应的列值为 NULL ，这就好像是先把左边的拼图块都摆出来，然后再去找能与之匹配的右边的拼图块。右连接和左连接类似，只是以右表为主。全外连接则会返回两个表中的所有行，如果没有匹配的行，则相应的列值为 NULL ，这相当于把所有的拼图块不管能不能匹配都放在一起。

二、优化连接查询的关键策略

（一）创建合适的索引

索引就像是数据库中的指南针，能帮助查询快速找到所需的数据。对于经常用于连接条件的列，创建索引可以大大提高连接查询的性能。

比如说，如果我们经常根据 users 表中的 user_id 列和 orders 表中的 user_id 列进行连接查询，那么在这两个列上创建索引就像是给查询之路铺上了高速公路。

CREATE INDEX idx_users_user_id ON users (user_id);
CREATE INDEX idx_orders_user_id ON orders (user_id);

但要注意，不要过度创建索引，否则就像在小路上设置了太多的路标，反而会让查询迷失方向。

（二）确保连接条件清晰准确

连接条件就像是连接查询的路线图，如果路线图模糊不清，查询就会迷路。确保连接条件准确无误，避免使用复杂或模糊的表达式。

例如，使用简单的相等比较 = 往往比使用复杂的函数或表达式更有效。

-- 好的示例
SELECT * FROM users u INNER JOIN orders o ON u.user_id = o.user_id;-- 不好的示例
SELECT * FROM users u INNER JOIN orders o ON function(u.user_id) = function(o.user_id);

（三）合理选择连接类型

根据实际需求选择合适的连接类型。如果只需要返回两个表中匹配的行，内连接通常是最佳选择。如果需要保留左表或右表中的所有行，即使没有匹配，再选择相应的左连接或右连接。

就像在旅行中，如果你只想去那些有美丽风景的地方，那就选择内连接；如果你不想错过出发地的任何风景，哪怕目的地没有什么特别的，那就选择左连接。

（四）减少数据量

在进行连接查询之前，尽量减少参与连接的表的数据量。可以通过使用子查询、分页等方式来实现。

比如说，如果你只需要查询最近一周的订单数据与用户信息进行连接，那么先通过子查询筛选出最近一周的订单数据，再进行连接。

SELECT * FROM users u INNER JOIN (SELECT * FROM orders o WHERE order_date >= CURRENT_DATE - INTERVAL '7 days') o 
ON u.user_id = o.user_id;

这就好比在一堆杂物中先挑出有用的部分，再进行整理，而不是一股脑地把所有东西都混在一起处理。

三、实战中的优化案例

为了让大家更直观地理解，让我给大家分享一个实际的案例。

假设我们有一个电商网站，有 users 表（用户信息）、 orders 表（订单信息）和 order_items 表（订单详情）。我们需要查询某个用户的所有订单及其详情。

最初的查询语句可能是这样的：

SELECT u.*, o.*, oi.* 
FROM users u 
JOIN orders o ON u.user_id = o.user_id 
JOIN order_items oi ON o.order_id = oi.order_id 
WHERE u.user_id = 123;

这个查询可能会非常慢，特别是当数据量很大的时候。

我们来逐步优化它。

首先，为 users 表的 user_id 列、 orders 表的 user_id 和 order_id 列以及 order_items 表的 order_id 列创建索引：

CREATE INDEX idx_users_user_id ON users (user_id);
CREATE INDEX idx_orders_user_id ON orders (user_id);
CREATE INDEX idx_orders_order_id ON orders (order_id);
CREATE INDEX idx_order_items_order_id ON order_items (order_id);

然后，考虑是否可以通过子查询先筛选出用户的订单，再进行连接：

SELECT u.*, o.*, oi.* 
FROM users u 
JOIN (SELECT * FROM orders WHERE user_id = 123) o ON u.user_id = o.user_id 
JOIN order_items oi ON o.order_id = oi.order_id;