GaussDB单SQL性能慢-视图分析

wang 2023-05-31

408

1、流控导致慢SQL

常见于批量导数、压测或者批量提交的场景。

a.在慢SQL出现的时间段内搜索sleep相关字样。

b.执行如下SQL语句，如果current_sleep_time字段有值说明有流控产生。

SELECT * FROMdbe_perf.global_recovery_status

2、并发锁冲突导致慢SQL

a.如果达到慢SQL阈值log_min_duration_statement，则查看statement_history的Top wait event。

SELECTstatement_detail_decode(details, 'plaintext', true) FROMDBE_PERF.get_global_slow_sql_by_timestamp('start time','end time') WHEREunqiue_sql_id = xxx;

b.如果慢SQL没有达到SQL阈值log_min_duration_statement，可以直接查看对应时间时间段的dbe_perf.local_active_session/gs_asp信息，查看对应的wait event，如果是实时的SQL慢则参考e。

c.如果Top Wait event为acquire lock，通过ASP信息分析lock的等锁超时，找到对应的block_sessionid，通过查询以下SQL，查询阻塞该语句的会话。

SELECT * FROM gs_asp WHEREsample_time > 'start_time' and sample_time < 'end_time' and query like 'xxx';

d.根据block sessionid找到对应的session信息。

SELECT * FROM gs_asp WHEREsample_time > 'start_time' and sample_time < 'end_time' and query like'xxx' and sessionid = $block sessionid;

e.实时运行SQL慢，找到对应的block_sessionid，通过查询以下SQL，查询阻塞该语句的会话。

SELECT a.*,b.wait_status, b.wait_eventFROM pgxc_stat_activity as a left join pgxc_thread_wait_status as b on a.pid =b.tid and a.sessionid = b. sessionid and a.coorname = b.node_name andb.sessionid = $block_sessionid;

f.分析找到的会话信息，如果该会话的wait event为wait cmd，说明该会话上的语句已经执行完成，等待客户端发信息。

3、表膨胀导致大量的死元组

a.如果达到慢SQL阈值log_min_duration_statement，则查看statement_history/ DBE_PERF.get_global_slow_sql_by_timestamp，如果data_io_time较高或者是n_blocks_fetched- n_blocks_hit加大，说明SQL加载大量的页面导致SQL时延增加。

SELECT * FROMDBE_PERF.get_global_slow_sql_by_timestamp('start time','end time');

b.如果SQL未达到慢SQL阈值，第一种可以考虑打开full SQL，set track_stmt_stat_level = ‘L1,L1’，需要注意打开会SQL会记录所有执行的语句（可以会话级别打开），会占用大量的磁盘，用完后要理解关闭；第二种可以考虑调用动态接口，对固定的慢进行跟踪。

SELECT * FROMdynamic_func_control('GLOBAL', 'STMT', 'TRACK', '{"3182919165","L1"}'); -- 抓此SQL的FULLSQL L2 SELECT * FROM dynamic_func_control('GLOBAL', 'STMT', 'UNTRACK','{"3182919165"}');      -- 取消抓取 SELECT * FROM dynamic_func_control('GLOBAL', 'STMT', 'LIST', '{}'); SELECT * FROM dynamic_func_control('LOCAL', 'STMT', 'CLEAN', '{}');

c.通过查看SQL的计划explain(buffers, analyze)查看具体的IO情况，如果语句走索引但是head fetch较大，扫描的行较少，说明需要做大量的可见性判断。

d.查看慢SQL对应的表的pgstat信息，如果n_dead_tup显示有大量的死元组，或者last_vacuum显示长时间未做vacuum，需要对相关的表做vacuum。

SELECT * FROM pg_stat_all_tableswhere relname = 'xxx';

4、业务语句不优、计划不优

a.收集SQL相关的表的结构、索引、表和索引大小等信息。

b.如果达到慢SQL阈值log_min_duration_statement，则查看statement_history/ DBE_PERF.get_global_slow_sql_by_timestamp，获取SQL的计划。

SELECT * FROMDBE_PERF.get_global_slow_sql_by_timestamp('start time','end time');

c.如果SQL未达到慢SQL阈值，第一种可以考虑打开full SQL，set track_stmt_stat_level = ‘L1,L1’，需要注意打开会SQL会记录所有执行的语句（可以会话级别打开），会占用大量的磁盘，用完后要理解关闭；第二种可以考虑调用动态接口，对固定的慢进行跟踪，以获取SQL的计划信息。

SELECT * FROMdynamic_func_control('GLOBAL', 'STMT', 'TRACK', '{"3182919165","L1"}'); -- 抓此SQL的FULLSQL L2 SELECT * FROM dynamic_func_control('GLOBAL', 'STMT', 'UNTRACK','{"3182919165"}');      -- 取消抓取 SELECT * FROM dynamic_func_control('GLOBAL', 'STMT', 'LIST', '{}'); SELECT * FROM dynamic_func_control('LOCAL', 'STMT', 'CLEAN', '{}');

d.或者通过explain查看语句的计划信息，具体方法参考1.2.8 执行计划常见问题。

根据SQL的计划信息和对应的表、索引的信息确认SQL语句是否可以优化，或者索引是否有缺失等。

gaussdb

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

GaussDB单SQL性能慢-视图分析

评论