神水资源网

一个提升PostgreSQL性能的小技巧
站长资源 2024/12/28 佚名
2 0

 在一个（差）的PostgreSQL 查询中只要一个小小到改动(ANY(ARRAY[...])to ANY(VALUES(...)))就能把查询时间从20s缩减到0.2s。从最简单的学习使用 EXPLAIN ANALYZE开始，到学习使用 Postgres community 大量学习时间的投入将有百倍时间到回报。

使用Postgres监测慢的Postgres查询

在这周早些时候，一个用于我们的图形编辑器上的小表（10GB，1500万行）的主键查询，在我们的一个（多个）数据库上发生来大的查询性能问题。

99.9%到查询都是非常迅速流畅的，但是在一些使用大量的枚举值的地方，这些查询会需要20秒。花费如此多到时间在数据库上，意味着使用者必须在浏览器面前等待图形编辑器的响应。很明显只因为这0.01%就会造成很不好到影响。

查询和查询计划

下面是这个出问题的查询
 

SELECT c.key,
    c.x_key,
    c.tags,
    x.name
 FROM context c
 JOIN x
  ON c.x_key = x.key
WHERE c.key = ANY (ARRAY[15368196, -- 11,000 other keys --)])
 AND c.x_key = 1
 AND c.tags @> ARRAY[E'blah'];

表X有几千行数据，表C有1500万条数据。两张表的主键值“key”都有适当的索引。这是一个非常简单清晰的主键查询。但有趣的是，当增加主键内容的数量，如在主键有11,000个值的时候，通过在查询语句上加上 EXPLAIN (ANALYZE, BUFFERS)我们得到如下的查询计划。
 

Nested Loop (cost=6923.33..11770.59 rows=1 width=362) (actual time=17128.188..22109.283 rows=10858 loops=1)
 Buffers: shared hit=83494
 -> Bitmap Heap Scan on context c (cost=6923.33..11762.31 rows=1 width=329) (actual time=17128.121..22031.783 rows=10858 loops=1)
    Recheck Cond: ((tags @> '{blah}'::text[]) AND (x_key = 1))
    Filter: (key = ANY ('{15368196,(a lot more keys here)}'::integer[]))
    Buffers: shared hit=50919
    -> BitmapAnd (cost=6923.33..6923.33 rows=269 width=0) (actual time=132.910..132.910 rows=0 loops=1)
       Buffers: shared hit=1342
       -> Bitmap Index Scan on context_tags_idx (cost=0.00..1149.61 rows=15891 width=0) (actual time=64.614..64.614 rows=264777 loops=1)
          Index Cond: (tags @> '{blah}'::text[])
          Buffers: shared hit=401
       -> Bitmap Index Scan on context_x_id_source_type_id_idx (cost=0.00..5773.47 rows=268667 width=0) (actual time=54.648..54.648 rows=267659 loops=1)
          Index Cond: (x_id = 1)
          Buffers: shared hit=941
 -> Index Scan using x_pkey on x (cost=0.00..8.27 rows=1 width=37) (actual time=0.003..0.004 rows=1 loops=10858)
    Index Cond: (x.key = 1)
    Buffers: shared hit=32575
Total runtime: 22117.417 ms

在结果的最底部你可以看到，这个查询总共花费22秒。我们可以非常直观的通过下面的CPU使用率图观察到这22秒的花费。大部分的时间花费在 Postgres和 OS 上, 只有很少部分用于I/O . 

一个提升PostgreSQL性能的小技巧

 在最低的层面，这些查询看起来就像是这些CPU利用率的峰值。CPU图很少有用，但是在这种条件下它证实了关键的一点：数据库并没有等待磁盘去读取数据。它在做一些排序，哈希以及行比较之类的事情。

第二个有趣的度量，就是距离这些峰值很近的轨迹，它们是由Postgres“取得”的行数（本例中没有返回，就看看再忽略掉吧）。 

一个提升PostgreSQL性能的小技巧

 显然有些动作在规则的有条不紊的浏览过许多行：我们的查询。
 
Postgres 的问题所在：位图扫描

下面是行匹配的查询计划

 

Buffers: shared hit=83494
 -> Bitmap Heap Scan on context c (cost=6923.33..11762.31 rows=1 width=329) (actual time=17128.121..22031.783 rows=10858 loops=1)
    Recheck Cond: ((tags @> '{blah}'::text[]) AND (x_key = 1))
    Filter: (key = ANY ('{15368196,(a lot more keys here)}'::integer[]))
    Buffers: shared hit=50919

Postgres 使用位图扫描表C. 当主键的数据量小的时候，它能有效的使用索引在内存里建立位图。如果位图太大，最优查询计划就改变查询方式了。在我们这个查询中，因为主键包含的数据量很大，所以查询就使用最优（系统自己判断的）的方式去检索查询候选行，并且立即查询所有和主键匹配的数据。就是这些¨放入内存¨和¨立即查询¨花费太多的时间（查询计划中的Recheck Cond）。

幸好只有30%的数据被导入到内存中，所以还不至于像从硬盘里读取那么坏。但它仍然对性能有非常明显的影响。记住，查询是非常简单的。这是一个主键查询所以没有很多明了的方式来确定它有没有戏剧性的重新架构数据库或应用程序。PGSQL-Performance mailing list给予了我们很大的帮助.
 
解决方案

这是我们喜欢开源和喜欢帮助用户的另外一个原因。Tom Lane是开源代码作者中最盛产的程序员之一，他建议我们做如下尝试：
 

SELECT c.key,
    c.x_key,
    c.tags,
    x.name
 FROM context c
 JOIN x
  ON c.x_key = x.key
WHERE c.key = ANY (VALUES (15368196), -- 11,000 other keys --)
 AND c.x_key = 1
 AND c.tags @> ARRAY[E'blah'];

把ARRAY改成VALUES，你能指出他们的不同点吗？

我们使用ARRAY[...]列举出所有的关键字以用来查询，但是这却欺骗了查询优化器。然而Values(...)却能够让优化器充分使用关键字索引。仅仅是一行代码的改变，并且没有产生任何语义的改变。

下面是新查询语句的写法，差别就在于第三和第十四行。
 

Nested Loop (cost=168.22..2116.29 rows=148 width=362) (actual time=22.134..256.531 rows=10858 loops=1)
 Buffers: shared hit=44967
 -> Index Scan using x_pkey on x (cost=0.00..8.27 rows=1 width=37) (actual time=0.071..0.073 rows=1 loops=1)
    Index Cond: (id = 1)
    Buffers: shared hit=4
 -> Nested Loop (cost=168.22..2106.54 rows=148 width=329) (actual time=22.060..242.406 rows=10858 loops=1)
    Buffers: shared hit=44963
    -> HashAggregate (cost=168.22..170.22 rows=200 width=4) (actual time=21.529..32.820 rows=11215 loops=1)
       -> Values Scan on "*VALUES*" (cost=0.00..140.19 rows=11215 width=4) (actual time=0.005..9.527 rows=11215 loops=1)
    -> Index Scan using context_pkey on context c (cost=0.00..9.67 rows=1 width=329) (actual time=0.015..0.016 rows=1 loops=11215)
       Index Cond: (c.key = "*VALUES*".column1)
       Filter: ((c.tags @> '{blah}'::text[]) AND (c.x_id = 1))
       Buffers: shared hit=44963
Total runtime: 263.639 ms

查询时间从22000ms下降到200ms，仅仅一行代码的改变效率就提高了100倍。

在生产中使用的新查询

即将发布的一段代码:
它使数据库看起来更美观轻松. 一个提升PostgreSQL性能的小技巧

 第三方工具

postgres慢查询不存在了。但是有谁乐意被0.1%不幸的少数折磨。要立即验证修改查询的影响，就需要Datadog来帮助我们判断修改是否是正确的。

如果你想要找出对Postgres查询改变的影响，可能需要几分钟来注册一个免费的Datadog账号。

广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！
www.sccsvx.com 神水资源网
39,976影音资源
44,792技术资源
21,817软件资源
651,128站长资源
一句话新闻
苹果官宣WWDC 2024！预计会有大批AI功能 - 2024/12/28

3月27日消息，苹果宣布2024年全球开发者大会（WWDC）将于6月10日至6月14日举行，巧合的是，这次大会与端午假期重合。

苹果官方表示：

在线参加 Apple 每年规模最大的开发者盛会。亲眼见证 Apple 最新平台、技术和工具的发布。了解如何创建和改进你的 App 和游戏。与 Apple 设计师和工程师互动交流，与全球开发者社区建立联系。以上活动均免费在线举行。

探索各种新的工具、框架和功能，助力你打造出理想的 App 和游戏。通过视频讲座学习新技能，与 Apple 专家进行一对一会面，以推进你的项目，完善你的构思。

Swift Student Challenge 旨在支持和鼓舞下一代开发者、创作者和企业家。太平洋时间 3 月 28 日，我们将公布今年的获奖者名单。获奖者将有资格参加在 Apple Park 举办的特别活动。我们还会选出 50 名杰出获胜者，他们将受邀前往库比提诺，获得为期三天的非凡体验，包括参加 Apple Park 的特别活动。

RTX 5090要首发 性能要翻倍！三星展示GDDR7显存

三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。

首次推出的GDDR7内存模块密度为16GB，每个模块容量为2GB。其速度预设为32 Gbps（PAM3），但也可以降至28 Gbps，以提高产量和初始阶段的整体性能和成本效益。

据三星表示，GDDR7内存的能效将提高20%，同时工作电压仅为1.1V，低于标准的1.2V。通过采用更新的封装材料和优化的电路设计，使得在高速运行时的发热量降低，GDDR7的热阻比GDDR6降低了70%。

更新日志

友情链接

杰晶网络 DDR爱好者之家 桃源资源网 杰网资源 富贵资源网 南强小屋 铁雪资源网 幽灵资源网 万梅资源网 狼山资源网 白云岛资源网 昆仑资源网 相思资源网 明霞山资源网 内蒙古资源网 黑松山资源网 茶园资源网 饿虎岗资源网 大旗谷资源网 常春岛资源网 岱庙资源网 兴国资源网 快活林资源网 蝙蝠岛资源网 帝王谷资源网 白云城资源网 伏龙阁资源网 清风细雨楼 天枫庄资源网 圆月山庄资源网 无争山庄资源网 神水资源网 移花宫资源网 神剑山庄资源网 无为清净楼资源网 金钱帮资源网 丐帮资源网 华山资源网 极乐门资源网 小李飞刀资源网 凤求凰客栈 风云阁资源网 金狮镖局 鸳鸯亭资源网 千金楼资源网 更多链接