快捷導(dǎo)航

如何解決PostgreSQL執(zhí)行語(yǔ)句長(zhǎng)時(shí)間卡著不動(dòng)不報(bào)錯(cuò)也不執(zhí)行的問題

更新時(shí)間：2024年02月02日 15:30:40 作者：溝溝里的農(nóng)民

某日開發(fā)同事上報(bào)一sql性能問題,一條查詢好似一直跑不出結(jié)果,查詢了n小時(shí),還未返回結(jié)果,這篇文章主要給大家介紹了關(guān)于如何解決PostgreSQL執(zhí)行語(yǔ)句長(zhǎng)時(shí)間卡著不動(dòng)不報(bào)錯(cuò)也不執(zhí)行問題的相關(guān)資料,需要的朋友可以參考下

1 問題現(xiàn)象

執(zhí)行SQL語(yǔ)句，卡著不動(dòng)，不成功也不執(zhí)行，就像掛住了一樣。

truncate table simple;

2 原因分析

一般來(lái)說(shuō)，語(yǔ)句呈現(xiàn)卡著的狀態(tài)，主要會(huì)是兩種原因比較多，

原因1：SQL語(yǔ)句是一個(gè)耗時(shí)操作，正常場(chǎng)景下執(zhí)行的時(shí)候本來(lái)就耗時(shí)。

原因2：SQL語(yǔ)句中涉及到的表或者說(shuō)對(duì)象處于鎖定狀態(tài)。

現(xiàn)在來(lái)看當(dāng)前的問題，truncate table simple; 我們看這個(gè)語(yǔ)句應(yīng)該會(huì)執(zhí)行的很快才對(duì)，

如果是delete * from simple;那如果simple表里面數(shù)據(jù)量大的話是會(huì)比較慢的。

因此，這里大概率是表被鎖住了。

3 數(shù)據(jù)庫(kù)表被鎖住了，如何處理?

3.1 查詢一下當(dāng)前數(shù)據(jù)庫(kù)的活動(dòng)監(jiān)控pg_stat_activity

執(zhí)行語(yǔ)句：

select pg_blocking_pids(pid),pid,now()-xact_start,wait_event,wait_event_type,substr(query,1,100) from pg_stat_activity where state <> ‘idle' order by 3 desc;

test=# select pg_blocking_pids(pid),pid,now()-xact_start,wait_event,wait_event_type,substr(query,1,100) from pg_stat_activity where state <> 'idle' order by 3 desc;
 pg_blocking_pids | pid |    ?column?     | wait_event | wait_event_type |                                                substr

------------------+-----+-----------------+------------+-----------------+----------------------------------------------------------------------------------------------
--------
 {}               | 592 | 00:53:35.188996 | ClientRead | Client          | lock table simple in access  exclusive mode;
 {592}            | 641 | 00:17:37.498617 | relation   | Lock            | truncate table simple;
 {}               | 750 | 00:00:00        |            |                 | select pg_blocking_pids(pid),pid,now()-xact_start,wait_event,wait_event_type,substr(query,1,1
00) fro
(3 rows)

通過(guò)上面執(zhí)行語(yǔ)句得到的結(jié)果，可以看到我們執(zhí)行truncate table simple的語(yǔ)句進(jìn)程id是641，它處于Lock狀態(tài)，Lock的原因是因?yàn)?92阻塞導(dǎo)致。

因此，要先解決592進(jìn)程。

3.2 中斷阻塞進(jìn)程

pg_terminate_backend(需要被中斷的進(jìn)程號(hào))

pg_terminate_backend函數(shù)說(shuō)明：

test=# select pg_terminate_backend(592);
 pg_terminate_backend
----------------------
 t
(1 row)

3.3 檢查前面的執(zhí)行是否成功

剛剛卡著的，中斷阻塞的進(jìn)程后，立刻就完成執(zhí)行了。如下圖所示：

4 pg_stat_activity表定義

                  View "pg_catalog.pg_stat_activity"

Column	Type	Collation	Nullable	Default
------------------±-------------------------±----------±---------±--------
datid	oid
datname	name
pid	integer
usesysid	oid
usename	name
application_name	text
client_addr	inet
client_hostname	text
client_port	integer
backend_start	timestamp with time zone
xact_start	timestamp with time zone
query_start	timestamp with time zone
state_change	timestamp with time zone
wait_event_type	text
wait_event	text
state	text
backend_xid	xid
backend_xmin	xid
query	text
backend_type	text

https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW

總結(jié)

到此這篇關(guān)于如何解決PostgreSQL執(zhí)行語(yǔ)句長(zhǎng)時(shí)間卡著不動(dòng)不報(bào)錯(cuò)也不執(zhí)行問題的文章就介紹到這了,更多相關(guān)PostgreSQL執(zhí)行語(yǔ)句長(zhǎng)時(shí)間不動(dòng)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: