PostgreSQL – PostgreSQL/PostGIS 性能调优

1、优化资源占用

无法对服务器环境预估,所以PostgreSQL配置中参数都比较保守,不是对服务器资源量身定制,都默认是最小。其中两个参数,根据服务器实际资源情况调整会对性能影响很大:

  • shared_buffers,缓存查询过程中的临时数据,内存的1/4比较合适,默认128M;
  • work_mem,sort和hash表操作需要占用的内存,不够用时,会向磁盘中写文件,磁盘的性能和内存相差可不少,默认4M;

2、频繁改动的表要周期性执行analyze

简单来说,PostgreSQL的query planner依赖统计查询所涉及的表的统计信息来做执行计划,如果统计信息不及时,那么执行计划可能并不是最高效的,甚至非常低效。执行analyze,可以更新指定表的统计信息,因此好的实践是按照一定规则的自动执行analyze。PostgreSQL提供了“autovacuum_analyze_threshold”参数和“autovacuum_analyze_scale_factor”参数,“autovacuum_analyze_threshold”设定对表执行update或insert影响到的行数,如果超过这个值,就会触发analyze;“autovacuum_analyze_scale_factor”设定如果表增加的体积超过指定的比例,则触发analyze操作。

根据你的数据实际情况和需求确定这两个值吧。

3、索引是不能少的

在图书馆里找一本书,如果没有各个书柜上的索引分类,在书海中抄到一本书。。也不是不可能,最好情况,你走运,看到的第一本就是,不走运时,翻遍了整个图书馆的几千万?本书,最后一本是你想要的书。平均情况,你找一本书也得用个几个月吧。所以,数据库的索引和图书馆的图书索引作用是一样的,原理也类似。

在任何的数据库中,建立索引都能极大的提升查询的性能,在Citus集群中也不例外。

在有可能查询在运行的表中创建索引,要注意添加上”concurrently“,这样不会对表上锁,不会阻止写操作。添加”concurrently“不会影响创建索引的性能。

4、explain && explain analyze

你以为的以为不是PostgreSQL Query Planer以为的以为,要分析一个查询的执行计划,进行优化,就得知道PostgreSQL是怎么计划的,使用explain可以查看执行计划。

优化查询时,explain和explain analyze是非常有用的工具,通过explain可以查看PostgreSQL的执行计划,explain和explain analyze不同之处在于explain不会真正执行查询,执行计划中的耗时是估计值,且并不是以毫秒为单位,而explain analyze会真正执行的查询,其执行计划中的耗时也是比较准确的数值,且耗时单位是毫秒。需要注意的一点是,explain analyze报告的最终执行耗时往往包含explain analyze自身的耗时,一般能占到查询耗时的30%,实际使用中,一个执行6分钟的查询,实测多占用时间甚至达到了50%。

所以使用explain analyze总耗时并不是真正查询耗时,其结果主要用于参考哪个过程耗时较长,可以优化。

5、连接池

pgbouncer vs pgpool-II

6、远离update

update不支持并行,一条一条更新,数据量大了,岂不是会等到天荒地老?

7、允许并行,根据你的硬件调整并行参数

“max_parallel_worker”

8、测试你的成果

sysbench

转载自:https://blog.csdn.net/qingyafan/article/details/88523513

You may also like...

退出移动版