背景:4172交易高于12并发后,db3偶发超时报错
排查过程
1、首先排查db3是否与其他db有差异
2、查询慢sql日志(gaussdb)
sql:gsql -p26000 -d postgres -x -c "select (finish_time - start_time) as exe_time,pg_catalog.statement_detail_decode(details,'plaintext',true),* from deb_perf.statement_history where user_name='cpcd' and start_time>'2024-01-11 19:30:16' and query like '%select * from table' order by db_time desc" >test.txt
注意:实际表数据=0,但是随机扫描何返回的tup很多,是因为扫描出来的是索引数据,重建db3问题解决
3、通过执行计划发现有74个分区表
4、查询分区表:
select * from pg_catalog.pg_partition where relname like '%tablename%';
--查询分表的表索引:select * from pg_catalog.pg_partitio where relname like %tablename%' and parttype='x';
5、通过建表语句查询分区键
select * from pg_catalog.pg_get_tabledef('tablename');
其中的 partition by range (file_date) 就是了
优化措施
- 分区表的查询优化器需要根据查询条件和分区定义来决定在哪些分区执行操作,如果分区数量过多,可能会增加优化器的计算开销,导致查询计划的生成时间较长
- 分区表的查询过程中,需要打开并锁住所有的底层表,如果分区数量过多,可能会增加打开和锁住表的时间,导致查询性能下降。
- 分区表的查询结果可能需要合并多个分区的数据,如果分区过多,会增加合并数据的时间,导致查询延迟增加
措施:
- 优化业务优先使用分区键,并且尽可能每次查询不要涉及太多分区
- 适当合并分区,减少分区数量