Postgres SQL sort 操做性能调优

这篇文章将以实战的方式结合笔者在项目中真实遇到的状况来说解。说到SQL，你们可能会遇到一些写法稍微复杂的写法。好比SQL中遇到的有聚合函数sum等，也有遇到使用group by / order by的状况，其实这种状况下SQL的性能可能不是特别好。至少有两种大的解决思路：

• 减小SQL的压力，把SQL实现的逻辑计算相关，用code的方式去解决。即释放数据库后端宝贵的计算资源。算是重构SQL，这种方式代价稍微要高些，由于要更改code的实现逻辑，也要规划好新的SQL的结构。目的就是为了在SQL中去掉order排序/group分组这类比较耗费资源的部分。

• 若是前提是咱们的SQL不能动，那么要怎么去优化呢？下面会一步步和你们解释在postgres中怎么调优order by SQL语句。

     step1:

    在Postgres中建立测试表，建立表SQL以下：

CREATE TABLE public.sort_test
(
    id bigint NOT NULL,
    salary numeric NOT NULL,
    CONSTRAINT sort_test_pkey PRIMARY KEY (id)
)

TABLESPACE pg_default;

  step2:    

 在测试表中插入多条数据，以下SQL,能够往上表中插入500万条数据。

insert into sort_test select generate_series(1,5000000),generate_series(1,5000000);

  step3:

  评估order by 性能问题，假设要评估select语句以下，SQL不是很复杂，能够说明问题便可。

select * from sort_test order by salary;

  step4:

 分析SQL执行计划，获取执行计划的SQL语句以下：

explain analyze select * from sort_test order by salary;

  step5:

 执行计划以下（注：若是上面SQL语句没有analyze关键字，那么执行计划就不会有Sort Method详细信息和actual time的信息。

"Sort  (cost=804270.42..816770.42 rows=5000000 width=14) (actual time=2688.920..3797.378 rows=5000000 loops=1)""  Sort Key: salary""  Sort Method: external merge  Disk: 122344kB""  ->  Seq Scan on sort_test  (cost=0.00..77028.00 rows=5000000 width=14) (actual time=0.071..476.958 rows=5000000 loops=1)""Planning Time: 0.193 ms""Execution Time: 4038.509 ms"

  

从以上的执行计划能够看到最小的节点（上面"->"处）的执行时间是0.071 ms,而到上一层Sort，就会发现执行时间就变为了2688.92 ms （注：这边是以actual time做为分析依据，你也能够以cost时间，都是能够的。

以上有个关键信息以下，这就说明此sql在执行的时候，postgres分配的work_mem的内存大小不够，只能从disk处抓取数据处理。那么从内存的角度来优化SQL，就须要增大work_mem参数值，上面说是用了大体122MB disk。而postgres默认的work_mem是 4MB。

Sort Method: external merge  Disk: 122344kB

那么修改work_mem,用下面方法，将work_mem大小设置为1GB.

SET work_mem = '1GB';

step6:

修改以后，再获取执行计划以下：

"Sort  (cost=633365.42..645865.42 rows=5000000 width=14) (actual time=1241.768..1526.102 rows=5000000 loops=1)""  Sort Key: salary""  Sort Method: quicksort  Memory: 430984kB""  ->  Seq Scan on sort_test  (cost=0.00..77028.00 rows=5000000 width=14) (actual time=0.046..498.029 rows=5000000 loops=1)""Planning Time: 0.095 ms""Execution Time: 1775.462 ms"

此时，能够看到关键字变为以下所示，sort操做如今是放在了内存中执行的，用了430MB左右的内存，而后执行时间为1241.768 ms，还不到原来执行时间的一半，性能仍是有大幅度提高的。

Sort Method: quicksort  Memory: 430984kB"

舒适提示：work_mem在调整时，仍是要考虑实际状况，好比我数据库跑一些轻量级的sql比较多，那么设置work_mem值过大的话，反而会影响性能,此时能够小幅度地调整参数值，须要测试多轮，获得适合本身产品的最优解。若是都是哪一种OLAP,SQL比较重的状况下，能够调整的幅度大一些，如从4MB调整到1GB.

你们也能够扫描并关注以下公众号“TimTest”，会有更多性能测试相关内容分享。