我們在很多地方應(yīng)該都聽到過長事務(wù)的危害，比方說長事務(wù)會導(dǎo)致表膨脹之類的。那么在PostgreSQL中什么才算是長事務(wù)呢？

首先，在PostgreSQL的官方文檔中并沒有所謂“長事務(wù)”這一定義，似乎大家約定俗稱的把一個執(zhí)行了很長卻沒有提交的事務(wù)認為是“長事務(wù)”了，而在不同的數(shù)據(jù)庫中關(guān)于長事務(wù)的定義往往也不盡相同，那么在PostgreSQL中什么是長事務(wù)呢？

打個比方，如下所示，我在一個會話中通過begin開啟一個事務(wù)，然后執(zhí)行了個簡單的查詢語句后遲遲不提交，這算不算長事務(wù)呢？

bill=# begin;
BEGIN
bill=*# select 1;
 ?column?
----------
        1
(1 row)

bill=*#

為了搞清楚這個問題，我們不妨想想，為什么我們會提到長事務(wù)呢。這是因為pg中的長事務(wù)會影響表中垃圾回收，會導(dǎo)致表的年齡增長無法freeze。而我們上面這個會話開啟的事務(wù)會有影響嗎？實際上并不會，我們可以通過pg_stat_activity視圖觀察：

bill=# select * from pg_stat_activity where pid = 26192;
-[ RECORD 1 ]----+------------------------------
datid            | 16385
datname          | bill
pid              | 26192
leader_pid       |
usesysid         | 16384
usename          | bill
application_name | psql
client_addr      |
client_hostname  |
client_port      | -1
backend_start    | 2022-03-02 11:49:49.433165+08
xact_start       | 2022-03-02 14:34:04.494416+08
query_start      | 2022-03-02 14:34:06.946754+08
state_change     | 2022-03-02 14:34:06.947207+08
wait_event_type  | Client
wait_event       | ClientRead
state            | idle in transaction
backend_xid      |
backend_xmin     |
query            | select 1;
backend_type     | client backend

之所以會導(dǎo)致表膨脹之類的問題，主要是在于backend_xid和backend_xmin兩個字段，而上面的事務(wù)這兩個字段均是空的。

/* ----------
 * LocalPgBackendStatus
 *
 * When we build the backend status array, we use LocalPgBackendStatus to be
 * able to add new values to the struct when needed without adding new fields
 * to the shared memory. It contains the backend status as a first member.
 * ----------
 */
typedef struct LocalPgBackendStatus
{
  /*
   * Local version of the backend status entry.
   */
  PgBackendStatus backendStatus;
  /*
   * The xid of the current transaction if available, InvalidTransactionId
   * if not.
   */
  TransactionId backend_xid;
  /*
   * The xmin of the current session if available, InvalidTransactionId if
   * not.
   */
  TransactionId backend_xmin;
} LocalPgBackendStatus;

backend_xid表示已申請事務(wù)號的事務(wù)，例如有增刪改，DLL等操作的事務(wù)。backend_xid從申請事務(wù)號開始持續(xù)到事務(wù)結(jié)束。

backend_xmin表示SQL執(zhí)行時的snapshot，即可見的最大已提交事務(wù)。

而表膨脹的原因是什么呢？當數(shù)據(jù)庫中存在未結(jié)束的SQL語句或者未結(jié)束的持有事務(wù)ID的事務(wù)，在此事務(wù)過程中，或在此SQL執(zhí)行時間范圍內(nèi)產(chǎn)生垃圾的話，這些垃圾無法回收，導(dǎo)致數(shù)據(jù)庫膨脹。

也就是判斷當前數(shù)據(jù)庫中backend_xid和backend_xmin最小的值，凡是超過這個最小值的事務(wù)產(chǎn)生的垃圾都不能回收。

因此，我們?nèi)绻胍O(jiān)控長事務(wù)該怎么寫呢？以超過1小時的長事務(wù)為例：

select count(*) from pg_stat_activity where state <> 'idle' 
and (backend_xid is not null or backend_xmin is not null) 
and now()-xact_start > interval '3600 sec'::interval;

所以，對于事務(wù)而言，只有當執(zhí)行了一些DML或者DDL操作后才能算是我們通常說的長事務(wù)。否則只能算是我們常說的長連接，當然長連接也有很多弊端，例如占用內(nèi)存、cpu等資源。

在實際應(yīng)用中，我們應(yīng)當做好對長事務(wù)的監(jiān)控，并盡可能的避免其發(fā)生。例如一些批量的操作可能會比較容易導(dǎo)致長事務(wù)，我們可以盡量將其安排在業(yè)務(wù)低峰期執(zhí)行，同時，如果我們的應(yīng)用中關(guān)閉了自動提交，也要在執(zhí)行完之后加上提交。

到此這篇關(guān)于PostgreSQL長事務(wù)概念解析的文章就介紹到這了,更多相關(guān)PostgreSQL長事務(wù)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論