PostgreSQL 在重負載下的設計與 SQL 注意事項

寫給耀達 Lite 雲端進銷存（2026-11-02）。接續 db-scaling.html、cache.html、alb.html、aurora-serverless.html。
前提：AWS 東京、Aurora PostgreSQL Serverless、C# ASP.NET Core＋Npgsql，所有店家共用資料表、用 RLS 隔開（第 5 題已定）。資料表名稱都是示範，資料模型還沒定。

1. 先講結論

重負載下最常出事的通常不是「SQL 不夠漂亮」，而是這三種情況：一筆交易開太久、一張表被太多人改同一列、查詢掃了太多不需要的資料。

2. 先懂 PostgreSQL 的四個脾氣

後面幾乎每條規則都能從這四點推出來。

脾氣一：改一列，其實是多寫一列

PostgreSQL 用 MVCC 讓「讀」和「寫」不互相擋。UPDATE 不會直接蓋掉舊資料，而是寫一個新版本，舊版本留著給還在看它的交易。沒有人需要舊版本之後，要等 VACUUM 回收。DELETE 也一樣，只是把列標成不要了。

由此推出：常被改的欄位不要建索引；太久沒結束的交易會讓舊版本回收不掉；資料刪了，空間也不會還給作業系統，只會留給這張表自己重複使用。

脾氣二：寫入者只擋同一列的寫入者，不擋讀

同時改同一列的第二個人要排隊，等第一個人的交易結束。文件原話是：只要沒有偵測到死結，等鎖的交易會無限期等下去，所以長時間開著交易（例如等使用者輸入時）是壞主意。

脾氣三：快不快，主要看資料是否已在記憶體

資料以 8 KB 為一頁存放。在記憶體裡的頁幾乎不用等；不在的話要去儲存層讀，慢很多，在 Aurora 上還可能算 I/O 費。Aurora Serverless 縮小時會把記憶體中的資料擠掉，再變大時要重新讀回來，所以「最小 ACU 放不放得下常用資料」會直接影響速度和帳單（aurora-serverless.html 第 5 節）。

脾氣四：查詢規劃器靠估計，估錯就選錯路

PostgreSQL 依統計資料估計每種做法的成本，再選最便宜的。統計資料由 ANALYZE 取樣而來，會過期，也會不準。所有店家共用一張表時，大店和小店的資料量差很多，這個問題會特別明顯（第 10 節）。

3. 店家隔離：從請求到資料列的整條鏈

RLS 不是開了就好。下面每一段都可能出錯，出錯的後果是把甲店的資料給乙店看到，所以這節排在最前面。

3.1 帳號要分開

3.2 規則怎麼寫

ALTER TABLE sales_order ENABLE ROW LEVEL SECURITY;
ALTER TABLE sales_order FORCE ROW LEVEL SECURITY;

CREATE POLICY store_isolation ON sales_order
  USING      (store_id = current_setting('app.store_id')::bigint)
  WITH CHECK (store_id = current_setting('app.store_id')::bigint);

USING 決定看得到哪些列，WITH CHECK 決定能寫入哪些列。current_setting 在 PostgreSQL 18 目錄裡標為 STABLE，AWS 的多租戶指引也是用同樣的寫法，只是型別為 uuid。

3.3 每筆交易都要設定

await using var conn = await dataSource.OpenConnectionAsync(ct);
await using var tx = await conn.BeginTransactionAsync(ct);

await using (var set = new NpgsqlCommand(
    "SELECT set_config('app.store_id', $1, true)", conn, tx))
{
    set.Parameters.AddWithValue(storeId.ToString());
    await set.ExecuteNonQueryAsync(ct);
}

// 這裡才開始做事。只讀也一樣要包在交易裡。

await tx.CommitAsync(ct);

• 為什麼不用 session 層的 set_config(…, false)：Npgsql 把連線還回池後，下次使用時會先重設狀態，正常情況下設定不會留給下一位。但實測打開 No Reset On Close 後，下一位沒設定店家編號也直接讀到上一家店的 20 張單。這種錯法完全不會報錯，所以不要依賴這一層。已實測
• 沒開交易、分兩個指令送：set_config(…, true) 在第一個指令結束時就失效，第二個指令會報錯。這正是我們要的結果：寫錯會馬上發現，不會讀到別家。已實測
• 為什麼不能放在 UsePhysicalConnectionInitializer：它只在實體連線建立時執行一次，而連線之後會輪流服務不同店家。
• 可以省一次往返：NpgsqlBatch 把多條陳述式打包送出，沒有明確開交易時也有隱含交易。set_config 加查詢用一個批次送出，店家編號在整個批次都有效，只要一次往返。已實測

3.4 外鍵和唯一約束：RLS 管不到的地方

PostgreSQL 文件明寫：外鍵、主鍵、唯一約束的檢查一律略過 RLS，並警告這是一條暗中探測資料的管道。實測結果如下：已實測

正確的寫法是全部帶上 store_id：

CREATE TABLE customer (
  store_id bigint NOT NULL,
  id       uuid   NOT NULL,
  code     text   NOT NULL,
  PRIMARY KEY (store_id, id),
  UNIQUE (store_id, code)
);

CREATE TABLE sales_order (
  store_id    bigint NOT NULL,
  id          uuid   NOT NULL,
  customer_id uuid   NOT NULL,
  PRIMARY KEY (store_id, id),
  FOREIGN KEY (store_id, customer_id) REFERENCES customer (store_id, id)
);

-- 外鍵不會自動建索引，參照端要自己建
CREATE INDEX ON sales_order (store_id, customer_id);

改成複合外鍵後，同樣的寫入被擋下（violates foreign key constraint）；兩家店也都能用 A001。已實測這也直接支援全站規則「被用到就不能刪，只能停用」：還被參照的客戶，資料庫本身就不讓刪。

3.5 其他會繞過 RLS 的路

• 檢視表（view）：預設用檢視表擁有者的權限讀底下的資料表。實測在沒開 FORCE 的表上，甲店透過檢視表看到了兩家店的資料。加 WITH (security_invoker = true) 或對表開 FORCE ROW LEVEL SECURITY 都只看到自己的。已實測
• SECURITY DEFINER 函式：同樣用函式擁有者的權限執行，除非必要否則不用。
• 新資料表忘了開 RLS：Claude 的看法：在自動測試裡查系統目錄，凡是有 store_id 欄位但沒開 RLS 的表，一律讓測試失敗。AWS 指引也建議所有含租戶資料的表都開 RLS。
• 備份工具：pg_dump 預設把 row_security 關掉，app_user 直接跑會報錯，不會默默只匯出部分資料。實測設 PGOPTIONS='-c app.store_id=7' 再加 --enable-row-security，只匯出 7 號店的資料。已實測這可以當第 9 題「只還原一家店」的候選做法之一，但完整流程還沒談。

4. 設計資料表

4.1 主鍵

主鍵都寫成 (store_id, id)，同一家店的資料就能靠索引集中查詢。id 用什麼，主要看下面這個實測結果。

已實測 店家大小懸殊、隨機寫入時是 78／101／132 MB；每家一次寫 20 列時是 61／138 MB（bigint／UUID v7），結論相同。

Claude 的看法：這裡改變了看法。Claude 原本傾向 UUID v7，實測後改成傾向資料庫序列的 bigint：一個人維運時最簡單，索引也最小。它的兩個缺點都有解：RDS Proxy 第一版大概不用（第 13 節），而且要分片時可以分開號碼範圍。這跟 deployment.md 寫的「主鍵不依賴全庫共用流水號」方向不同，要一起重新討論，正式決定留到資料模型那一題。不管選哪一種，對使用者顯示的單號都另外編。

4.2 單號：序列做不到，要用計數列

LiteErp 的單號格式已定：單據字母＋年＋月日＋當天第幾張（例如 E2610090001）。這是「每家店、每種單據、每天」各自從 1 開始，序列做不到；而且序列本身也不保證連號，交易失敗時取走的號碼不會退回。所以要用一張計數表：

INSERT INTO doc_counter (store_id, doc_type, doc_date, last_no)
VALUES ($1, $2, $3, 1)
ON CONFLICT (store_id, doc_type, doc_date)
DO UPDATE SET last_no = doc_counter.last_no + 1
RETURNING last_no;

• 好處：跟單據在同一筆交易裡。交易失敗，號碼一起復原，不會因為失敗而跳號。實測中間 ROLLBACK 一次，下一張仍然是 2 號；同樣情況的序列則跳了號。已實測
• 代價：這一列會被鎖到交易結束，同一家店同時開同一種單據時要排隊。店內同時開單的人不多，應該還好，但這筆交易更要短。
• 順序：Claude 的看法：單據交易裡最後才取號，縮短鎖住的時間，也讓所有交易的取鎖順序一致。
• 還沒定的：作廢或刪除單據後能不能留下空號。這可能跟電子發票那一題有關。

4.3 欄位型別

4.4 時區：「今天」是哪一天

AWS 主機的時區不一定是台灣時間。如果用 now()::date 算日期，timestamptz 轉 date 會依連線的時區設定，台灣早上 8 點前的單據可能被算到前一天。實測連線時區是 UTC 時，台灣時間 11 月 2 日早上 7 點會算成 11 月 1 日。已實測

Claude 的看法：單據日期由程式依台灣時間決定，當成 date 參數傳進去。要在 SQL 裡換算時，明確寫 created_at AT TIME ZONE 'Asia/Taipei'，不要依賴主機設定。

4.5 約束盡量放資料庫

程式會有 bug，多台容器也可能同時執行，只靠 C# 先查再寫擋不住重複。

• 該有值的欄位加 NOT NULL。
• 會重複的東西一定靠 UNIQUE（帶 store_id）擋，C# 先查只是為了給好看的錯誤訊息。
• 數量、金額的範圍用 CHECK。
• 每張表都要有主鍵。沒有主鍵的表，在 Blue/Green 升級時不能做 UPDATE、DELETE。

4.6 會被頻繁更新的表

庫存餘額就是典型。整體作法是讓更新盡量走 HOT：

CREATE TABLE stock_level (
  store_id     bigint  NOT NULL,
  warehouse_id uuid    NOT NULL,
  product_id   uuid    NOT NULL,
  qty          numeric NOT NULL,
  updated_at   timestamptz NOT NULL,
  PRIMARY KEY (store_id, warehouse_id, product_id)
);

• qty、updated_at 不要建索引，否則每次更新都不符合 HOT。「庫存低於安全存量」這種查詢，掃這家店的列再過濾就好。
• fillfactor：資料表預設 100（塞滿）。調低會在每頁留空位，讓新版本可以放在同一頁，但下面的實測顯示影響遠不如索引，第一版不用調。
• 把常改的欄位跟很少改的欄位分開放，例如商品基本資料不要跟庫存數字擺在同一張表。

已實測 多一個索引，HOT 全部失效，索引變成 9 倍大。

4.7 自動存與寫入量

資料頁、設定頁改完自動存，單據要按儲存（LiteErp 2026-10-29 定的）。自動存的頁面要注意：UPDATE 就算寫入相同的值，也會產生一個新版本（實測列的位置從 (0,1) 變成 (0,2)）。已實測所以前端只在值真的變動時才送，後端只更新有變動的欄位。

5. 設計索引

索引的基本原理見 db-scaling.html 第 2 節。這裡只講設計時的判斷。

5.1 欄位順序：等號在前，範圍和排序在後

-- 清單頁：某家店，依日期新到舊
SELECT id, doc_no, doc_date, total
FROM sales_order
WHERE store_id = $1
ORDER BY doc_date DESC, id DESC
LIMIT 50;

-- 對應的索引：順序跟查詢一致，連排序都省了
CREATE INDEX ON sales_order (store_id, doc_date DESC, id DESC);

多欄 B-tree 在最左邊的欄位有條件時效率最好。PostgreSQL 18 新增 skip scan，可以跳過前面的欄位，但不要把它當成可以亂排順序的理由。

5.2 索引不是免費的

• 每個索引都會拖慢寫入、佔空間、吃記憶體，還可能破壞 HOT。
• AWS 的等待事件文件也建議刪掉用不到和重複的索引，來減輕頁面競爭。
• Claude 的看法：一開始只建主鍵、唯一約束、外鍵、主要清單頁需要的索引，其他等 pg_stat_statements 看到慢查詢再加。上線後定期查沒被用過的索引（第 15 節）。

5.3 幾種特別的索引

6. RLS 會讓某些索引條件失效

一般 PostgreSQL 教學通常不會提這件事，但它會直接影響搜尋功能的設計。本節的行為除了 jsonb 都實測確認了。已實測

為什麼會這樣

函式可能在錯誤訊息裡洩漏它看過的值。假設有一個條件在 RLS 檢查之前就先跑，別家店的資料就可能經由這個函式外洩。所以 PostgreSQL 規定：只有標記為 LEAKPROOF（保證不洩漏）的函式，才能排在 RLS 條件前面。

文件明寫：如果運算子底層的函式不是 LEAKPROOF，在有 RLS 的資料表上不能選用索引掃描來處理這個條件。原始碼也是同一個規則（indxpath.c 的 restriction_is_securely_promotable）。

哪些條件受影響

下表直接查自 PostgreSQL 18 的函式目錄（pg_proc.dat）：

鍵集分頁常用的 (doc_date, id) < ($1, $2) 不受影響：原始碼對列比較是逐欄判斷，date、uuid 都是 LEAKPROOF，實測也走索引。但如果比較的欄位裡有 numeric，那一欄就會造成問題。

實測結果

可以怎麼處理

7. 下 SQL 時要注意的事

7.1 鍵集分頁

-- 第一頁
SELECT id, doc_no, doc_date, total
FROM sales_order
WHERE store_id = $1
ORDER BY doc_date DESC, id DESC
LIMIT 50;

-- 下一頁：帶入上一頁最後一列的 doc_date 與 id
SELECT id, doc_no, doc_date, total
FROM sales_order
WHERE store_id = $1
  AND (doc_date, id) < ($2, $3)
ORDER BY doc_date DESC, id DESC
LIMIT 50;

不管翻到多後面，速度都差不多，因為索引直接跳到那個位置。代價是不能直接跳到第 37 頁，這會影響畫面設計。Claude 的看法：單據清單改用「下一頁」或無限捲動，加上日期篩選；真的要頁碼的小型資料（例如倉庫清單）用 OFFSET 也沒關係。

7.2 匯入大量資料：COPY 不能用

LiteErp 的商品、客戶匯入可以改用陣列參數，一句寫入多列，語句長度固定。這句實測可用，也能同時更新已存在的編號：已實測

INSERT INTO product (store_id, id, code, name)
SELECT current_setting('app.store_id')::bigint, id, code, name
FROM unnest($1::uuid[], $2::text[], $3::text[]) AS t(id, code, name)
ON CONFLICT (store_id, code)
DO UPDATE SET name = EXCLUDED.name;

一次匯入很多列時，分成每批幾百到幾千列，每批一筆交易，避免單一交易開太久。批次大小要實測。

7.3 不用怕但要知道的

• CTE（WITH）：PostgreSQL 12 起，沒有副作用、只用一次的 CTE 會併進主查詢，不會變慢，可以放心拿來整理 SQL。
• JOIN：有對應索引時不用怕。關聯式資料庫就是做這件事的，不必把它全部拆回 C# 再組。
• ON CONFLICT 會消耗序列值：就算最後什麼都沒寫入，nextval 也已經被呼叫。實測 ROLLBACK 一次、衝突一次之後，下一筆的編號是 4。已實測

7.4 跟 ORM 有關的注意

如果使用 EF Core，SQL 是它產生的，上面這些規則還是適用。Claude 的看法：單據、庫存、報表這些關鍵路徑直接寫 SQL 或看過產生的 SQL，一般資料頁再用 ORM。EF Core 怎麼跟每筆交易的 set_config 接起來，還沒查證（第 17 節）。

8. 看懂執行計畫

BEGIN;
SELECT set_config('app.store_id', '42', true);
EXPLAIN (ANALYZE)
SELECT id, doc_no FROM sales_order
WHERE doc_date >= '2026-10-01'
ORDER BY doc_date DESC, id DESC LIMIT 50;
ROLLBACK;

EXPLAIN ANALYZE 真的會執行語句，所以 UPDATE、DELETE 一定要包在 BEGIN…ROLLBACK 裡。PostgreSQL 18 起，它會自動附上 BUFFERS 資訊；舊版要自己寫 EXPLAIN (ANALYZE, BUFFERS)。

9. 交易、鎖與庫存

進銷存最核心的同時更新問題就在這裡：兩張銷貨單同時扣同一個商品。

9.1 不要先讀再寫

-- 錯：兩個請求都讀到 10，都寫回 8，實際賣了 4 個，帳上只少 2 個
SELECT qty FROM stock_level WHERE …;
-- C# 算 qty - 2
UPDATE stock_level SET qty = 8 WHERE …;

-- 對：讓資料庫原子地扣
UPDATE stock_level
SET qty = qty - $1, updated_at = now()
WHERE store_id = $2 AND warehouse_id = $3 AND product_id = $4
RETURNING qty;

預設的 READ COMMITTED 隔離層級下，第二個 UPDATE 會等第一個交易結束，然後根據更新後的資料重新判斷條件、計算新值，所以不會少扣。

已實測

負庫存要不要擋還沒決定。如果要擋，加上 AND qty >= $1，然後看更新了幾列，0 列就表示不夠。實測庫存 100、8 條連線共搶 800 次，最後剛好是 0，不會變負數。已實測

9.2 一次動多個商品：照固定順序鎖

-- 先依商品編號排序鎖好，再逐項更新
SELECT product_id, qty
FROM stock_level
WHERE store_id = $1 AND warehouse_id = $2 AND product_id = ANY($3)
ORDER BY product_id
FOR UPDATE;

實測兩筆交易用相反順序更新兩列，約 1 秒後其中一筆被取消（40P01）；都先照順序 FOR UPDATE 時，兩筆都成功。已實測

Claude 的看法：銷貨、進貨、調撥、組合、盤點共用同一個「異動庫存」元件，順序固定為：先庫存（依倉庫、商品排序），最後取單號。調撥、組合這類一張單動到多個倉庫或商品的尤其要小心。

9.3 死結和序列化失敗要重試

• PostgreSQL 預設等 1 秒（deadlock_timeout）才開始檢查死結，然後取消其中一筆交易，錯誤碼 40P01。
• 用 REPEATABLE READ 或 SERIALIZABLE 時，可能收到 40001。
• 文件明寫：要重試整筆交易，不是只重試失敗的那一句。包含 set_config 都要重來。
• Npgsql 的 PostgresException.IsTransient 可以用來判斷。實測 40001、40P01、55P03（等鎖逾時）、53300（連線數滿）、57P01（管理員關閉）是 true；57014（語句逾時）、23505（重複鍵）、42501（權限不足）是 false。這只是抽查，不是完整清單。已實測
• Claude 的看法：統一的重試元件，最多 3 次，每次隨機等一下。第一版用預設的 READ COMMITTED，不要全站開 SERIALIZABLE。

9.4 交易裡不能做的事

已實測 這是資料庫在本機的數字，沒有網路延遲。腳本寫的是等 5、50 毫秒，Windows 上實際約 15、60 毫秒，時間是從每秒筆數換算的。同一列一次只能一個人改，所以交易每多開一點時間，上限就直接掉下來。熱門商品的庫存列就是這種情況。

9.5 用資料庫當工作佇列

背景工作（成本計價、匯出）可以先用一張表當佇列，第一版不一定要多加 SQS。FOR UPDATE SKIP LOCKED 讓多個工作者各拿不同的工作，不用互等，文件也寫它適合佇列型的表：

SELECT id, payload
FROM job_queue
WHERE status = 'pending'
ORDER BY id
LIMIT 10
FOR UPDATE SKIP LOCKED;

注意：背景工作者要能拿到所有店的工作，所以這張佇列表的權限要另外設計。頻繁更新也會產生大量死資料，要跟第 11 節一起看。

9.6 一定要設逾時

下面這些設定預設全部是 0（不限制）。沒設的話，一個忘記結束的交易可以卡到天荒地老。

-- 數字只是起始值
ALTER ROLE app_user SET statement_timeout = '15s';
ALTER ROLE app_user SET lock_timeout = '5s';
ALTER ROLE app_user SET idle_in_transaction_session_timeout = '30s';
ALTER ROLE app_user SET transaction_timeout = '60s';  -- PostgreSQL 17 起

Claude 的看法：用 ALTER ROLE 設定，程式不必另外下 SET，也就不會多一個釘住的原因。報表、背景工作用另一個帳號，給比較長的時間。statement_timeout 要比 Npgsql 的 Command Timeout（預設 30 秒）短，讓資料庫自己先停下來。

10. 預備陳述式與統計資料

10.1 大店小店共用一個計畫的風險

預備陳述式的前 5 次都依實際參數規劃（custom plan），之後 PostgreSQL 會算一個通用計畫（generic plan），如果估計成本沒有明顯比較貴，就會改用它。而連線又會輪流服務不同店家。

實測發現：規劃器規劃時會讀當下的店家編號來估計列數（42 號店估 100 萬列、7 號店估 44 列），但存起來的計畫不會因為換了店家而重新規劃。所以第一個建立計畫的店家，會影響後面的店家：

已實測 風險是不對稱的：大店用小店的計畫只慢一點，小店用大店的計畫會慢幾百倍。

• Npgsql 的預設：Max Auto Prepare 預設 0，自動預備是關的。手動 Prepare() 的語句，實測在連線還回池之後仍然存在，所以計畫也會留著。已實測
• Claude 的看法：所有查詢都明寫 store_id = $1，RLS 當第二道防線。這比原本只把它當保險多了一個效能上的理由。第一版不開自動預備，有壓力測試資料後再比較。
• Aurora 的工具：有 Query Plan Management（apg_plan_mgmt）可以固定計畫、防止計畫變差。要 rds_superuser 安裝、設 rds.enable_plan_management=1 並重開。第一版用不到。

10.2 統計資料

• 預設只取樣這麼多：default_statistics_target 預設 100。實測 2000 家店的表，統計資料只單獨記錄了 42 號大店，並把店家數估成 900 家；其他店都用平均值。已實測必要時可以對單欄調高：ALTER TABLE sales_order ALTER COLUMN store_id SET STATISTICS 1000;。
• 欄位有關聯時估計會錯：規劃器預設假設欄位之間獨立。store_id 和 warehouse_id 明顯有關（倉庫只屬於一家店），估計可能差很多。可以建擴充統計：

  CREATE STATISTICS sales_order_store_wh (dependencies, mcv)
    ON store_id, warehouse_id FROM sales_order;
  ANALYZE sales_order;

• 統計何時更新：autovacuum 預設在 10% 的列變動後才重新 ANALYZE。大量匯入後可以手動跑一次。

11. VACUUM、膨脹與交易編號

11.1 大表的預設門檻太鬆

autovacuum 預設的開始條件是：死資料列超過 50 + 20% × 總列數。

共用資料表會把所有店家放在同一張表，表變大的速度比一家一表快很多，所以需要逐表調低：

-- 數字只是示範，要看監控調整
ALTER TABLE stock_level SET (
  autovacuum_vacuum_scale_factor  = 0.02,
  autovacuum_analyze_scale_factor = 0.02
);

Claude 的看法：庫存餘額、計數表、工作佇列這幾張常被更新的小表最先調。不要把 autovacuum 關掉。

11.2 長交易會讓 VACUUM 白做

只要還有一筆舊交易可能需要舊版本，VACUUM 就不能回收它。實測開著一個 REPEATABLE READ 交易時更新 1 萬列，VACUUM 回報 0 removed, 10000 are dead but not yet removable；交易結束再跑一次，1 萬列都回收了。已實測

一個開了好幾小時的交易可能讓全庫的表一起膨脹，這也是第 9.6 節要設逾時的原因之一。讀取器上的長交易會不會造成同樣的效果，Aurora 的行為還沒查證。

11.3 刪資料不會讓空間變小

• 一般 VACUUM：空間留在表內重複使用，不還給作業系統。
• VACUUM FULL：會重寫整張表，還要 ACCESS EXCLUSIVE 鎖，上線期間基本上不能用。
• pg_repack：Aurora 支援的擴充功能（PostgreSQL 14～18），可以線上重整。Aurora 的儲存費也要靠它才會下降（aurora-serverless.html 第 7 節）。
• 索引膨脹可以用 REINDEX INDEX CONCURRENTLY。

11.4 刪除整家店：分批慢慢刪

第 5 題接受的代價之一。不要一句刪完，要分批，每批一筆交易，中間留空檔讓 autovacuum 跟上：

DELETE FROM sales_order_line
WHERE (store_id, id) IN (
  SELECT store_id, id FROM sales_order_line
  WHERE store_id = $1
  LIMIT 5000
);
-- 回傳 0 列才算刪完；有外鍵時先刪子表

11.5 交易編號回捲

PostgreSQL 的交易編號是 32 位元的循環數字，每張表都必須定期做「凍結」清理。達到 autovacuum_freeze_max_age（預設 2 億）時會強制進行。真的放著不管，資料庫最後會拒絕新交易來保護資料。

Aurora 預設開啟 adaptive autovacuum（rds.adaptive_autovacuum），MaximumUsedTransactionIDs 太高時會自動加強清理；但 AWS 文件仍明寫回捲還是有可能發生，建議自己設告警。

12. 不停機改資料表

12.1 最危險的不是鎖本身，是排隊

SET lock_timeout = '2s';
ALTER TABLE sales_order ADD COLUMN note text;
-- 失敗就等一下再試，遷移工具要能重試

已實測 從 pg_blocking_pids 看得到 SELECT 是被 ALTER TABLE 擋住，ALTER TABLE 才是被長查詢擋住。第二組的長查詢持有鎖約 6 秒。

12.2 常見改動怎麼做

12.3 新舊版程式會同時跑

Fargate 滾動部署時，舊容器要排空（alb.html 第 8 節）才會關掉，所以有一段時間新舊程式同時連資料庫。因此：

1. 每次資料表改動，舊版程式都要還能跑。
2. 加東西：先改資料表，再部署程式。
3. 刪東西：先部署不再使用的程式，下一次才刪。

12.4 大版本升級

Aurora PostgreSQL 支援 Blue/Green 部署，AWS 說切換通常不到一分鐘，但底層是邏輯複寫，有不少限制：

• 升級期間做 DDL 會讓複寫降級，要重建部署。
• 沒有主鍵的表不能 UPDATE、DELETE（第 4.5 節）。
• 不支援新增分割區，pg_partman 要在藍環境停用；綠環境的 pg_cron 要保持停用。
• 寫入量很大時，單執行緒套用可能追不上，AWS 建議改用其他方式。
• 切換後，時間點還原的歷史會重新起算。

12.5 補舊資料要用對帳號

第 3.1 節讓 migration_owner 也受 RLS 限制，所以它改結構沒問題，但跑 UPDATE 補資料時沒有設定店家編號，第 3.2 節的規則會讓它直接報錯。已實測

Claude 的看法：補資料用 BYPASSRLS 的帳號分批跑，或一家店一家店設定編號再跑。這也是規則要「報錯」而不是「回傳空結果」的另一個理由：如果是後者，補資料的語句會顯示更新了 0 列，看起來像成功，其實什麼都沒做。

13. 連線與 Npgsql

13.1 連線不是越多越好

AWS 文件明寫：連線就算閒置也會消耗記憶體和 CPU。同時能真正做事的連線數，大致只跟 CPU 核心數有關，超過之後只是在互搶資源。而且 Serverless 的連線上限是依最大 ACU 算的（aurora-serverless.html 第 9 節）。

13.2 Npgsql 預設值

已實測 下表數值從 Npgsql 10.0.3 讀出，跟文件一致。

不要打開 Multiplexing：現行文件頁面已經查不到它；GitHub 上有一個標題為「Remove multiplexing」的 issue，屬於 11.0 里程碑（只看到標題，沒讀內文）。多筆交易共用連線也跟「交易內設定店家編號」的做法不一定合得來，未實測。

13.3 RDS Proxy：這次查到更多證據

第 7 題要用的資料。文件原文列出的，跟我們有關的釘住條件：

• 「Using SET commands.」
• 「Setting a parameter… Specifically, using SET and set_config commands to assign default values to session variables.」
• 新的一條：「If you use connection pooling libraries with DISCARD ALL query configured as a reset query, RDS Proxy pins your client connection on release.」

而 Npgsql 預設還回連線時就是做這件事。實測從資料庫紀錄看到：連線上沒有預備陳述式時送 DISCARD ALL；有的話送 SET SESSION AUTHORIZATION DEFAULT;RESET ALL;CLOSE ALL;UNLISTEN *;SELECT pg_advisory_unlock_all();DISCARD SEQUENCES;DISCARD TEMP。已實測

所以就算撇開 set_config，Npgsql 預設值加上 RDS Proxy 也可能造成釘住。這一步還要接上真正的 RDS Proxy 才能確認。未實測

文件仍然沒講的：PostgreSQL 上的 SET LOCAL、set_config(…, true) 會不會釘住；協定層的預備陳述式會不會釘住。要實測時看 CloudWatch 的 DatabaseConnectionsCurrentlySessionPinned。這些都強化了「第一版不用 Proxy」的看法，但還沒拍板。

13.4 寫入器和讀取器分兩個資料來源

Claude 的看法：開兩個 NpgsqlDataSource，一個連寫入器 endpoint、一個連讀取器 endpoint。Npgsql 也有多主機與 Target Session Attributes，但它的文件沒有提到 Aurora。第一版只有一台時，兩個可以指向同一台，以後加讀取器不用改程式。讀取器 endpoint 是在開連線時分配到各台主機，不是每一句分配。

14. Aurora 跟一般 PostgreSQL 不一樣的地方

網路上大部分 PostgreSQL 調校文章是寫給自己管主機的人。Aurora 的儲存層不同，有些建議不適用。

15. 監控與查問題

這節提供工具，告警門檻留給第 8 題。

15.1 要打開的工具

15.2 最常用的幾句查詢

已實測 以下都跑過。本機要先把 pg_stat_statements 放進 shared_preload_libraries、重開，再 CREATE EXTENSION。

-- 花最多時間的查詢
SELECT calls,
       round(total_exec_time) AS total_ms,
       round(mean_exec_time::numeric, 1) AS mean_ms,
       rows,
       shared_blks_read,
       left(query, 80) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

-- 開最久的交易
SELECT pid, now() - xact_start AS xact_age, state, left(query, 80) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start
LIMIT 20;

-- 誰被誰擋住
SELECT pid, pg_blocking_pids(pid) AS blocked_by,
       wait_event_type, wait_event, left(query, 80) AS query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

-- 死資料最多的表，以及 HOT 更新的比例
SELECT relname, n_live_tup, n_dead_tup, n_tup_upd, n_tup_hot_upd, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

-- 從沒用過的索引（主鍵、唯一索引除外）
SELECT s.relname, s.indexrelname, s.idx_scan,
       pg_size_pretty(pg_relation_size(s.indexrelid)) AS size
FROM pg_stat_user_indexes s
JOIN pg_index i ON i.indexrelid = s.indexrelid
WHERE s.idx_scan = 0 AND NOT i.indisunique AND NOT i.indisprimary
ORDER BY pg_relation_size(s.indexrelid) DESC;

-- 建失敗留下的索引
SELECT indexrelid::regclass FROM pg_index WHERE NOT indisvalid;

-- 交易編號離回捲還有多遠
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY 2 DESC;

15.3 等待事件：資料庫在等什麼

AWS 建議「減少外鍵」是針對這個等待事件。Claude 的看法：多租戶下複合外鍵是安全防線，第一版不要為了效能拿掉，除非量到它真的是瓶頸。

15.4 找問題的順序

1. 先看 Database Insights：負載是 CPU、I/O，還是鎖？
2. 從 pg_stat_statements 找花最多總時間的查詢（不是最慢的那一句）。
3. 用 app_user 帶店家編號跑 EXPLAIN (ANALYZE)，大店小店各跑一次。
4. 修查詢或索引，再量一次。

16. 對耀達 Lite 的意義

16.1 從第一天就要做對（事後很難改）

16.2 上線前要做

• 壓力測試資料：一家超大店（例如 100 萬張單、10 萬個商品）加上幾千家小店。只有平均資料是測不出第 6、10 節問題的。
• 測試用 app_user 跑，並開著 pg_stat_statements。
• 隔離測試：以甲店身分讀寫乙店資料，每張表都要失敗；連線重複使用後讀不到上一家店的編號。
• 同時操作測試：同時賣同一個商品，庫存要對得上；反向順序開兩張單不會死結。
• 調整常被更新的表的 autovacuum 參數。

16.3 可以等監控數字再做

• 更多索引、自動預備陳述式。
• 分割表、分片（db-scaling.html）。
• 讀取器、Query Plan Management、搜尋服務。

16.4 這份文件帶出的待決事項

17. 還沒查證的事

實測的範圍與限制

2026-11-02 在本機跑了第 1～15 節標 已實測 的項目：Windows、6 核心、PostgreSQL 18.6（shared_buffers 1 GB、C 定序）、Npgsql 10.0.3。

• 不是 Aurora：儲存層、Serverless 變動容量、網路延遲都不一樣。絕對數字不能拿來估正式環境，但「用不用得上索引」「計畫怎麼選」「鎖怎麼排隊」這類行為，引擎相同的部分應該一致。
• 測試資料很極端：大店佔整張表 96%，全表掃描比真實情況更容易出現；資料都在記憶體裡，幾乎沒有 I/O 成本。
• 多數查詢只跑一次，而且部分測試同時在跑，沒有取平均。

還要到 AWS 上才能確認的

• 第 13 節：RDS Proxy 下 SET LOCAL、set_config(…, true)、Npgsql 重設指令的釘住情況。
• 第 14 節：讀取器取消查詢的情況、連線池與自動暫停的時間、Aurora 上的 I/O 計費。
• 大店佔比低、資料超過記憶體時，RLS 下逐列過濾的實際成本。

查不到或只有二手資料的

• hot_standby_feedback 在 Aurora 的行為：第三方說「一律開啟、可能造成膨脹」，官方頁面沒查到。這決定讀取器上的長查詢會不會影響寫入器清理。
• Aurora 主帳號（rds_superuser）會不會略過 RLS、能不能設 LEAKPROOF。
• Materialized view 跟 RLS 的互動：寫這份文件時沒查，彙總表不要假設會受到保護。
• pg_stat_statements、auto_explain 在 Aurora 的預設狀態與開法。
• Database Insights 的最小 ACU 建議；Advanced 的實際費用；Query Plan Management 是否另外收費。
• Aurora 的儲存法定數（4/6）：這次讀的官方頁面沒看到這個數字，文中不採用。
• Npgsql IsTransient 的完整錯誤碼清單（這次只抽查 8 個）、EF Core 重試的預設次數。

這次沒有研究的

• 中文排序與定序（collation）：品名怎麼排才符合台灣習慣，以及它跟索引的關係。
• EF Core 的整合：怎麼在每筆交易注入 set_config（interceptor 或自己包）、AddDbContextPool 的影響、遷移裡怎麼做 CONCURRENTLY。
• 分割表跟 RLS 合用的細節。
• 單號的法規或實務需求：是否必須連號。

18. 名詞對照

19. 來源

PostgreSQL 文件（current，寫作時為 18）

• Row Security Policies（誰會略過、FORCE、外鍵與唯一性略過 RLS）
• Rules and Privileges（非 LEAKPROOF 運算子不能選用索引掃描）
• CREATE FUNCTION（LEAKPROOF 只有超級使用者能設）
• CREATE VIEW（security_invoker）
• Configuration Settings Functions（set_config、current_setting）
• pg_dump（--enable-row-security）
• COPY（有 RLS 的表不支援 COPY FROM）
• Populating a Database（COPY 比 INSERT 快）
• Heap-Only Tuples（HOT 條件）
• CREATE TABLE、CREATE INDEX（fillfactor、CONCURRENTLY、INVALID）
• Constraints（外鍵不會自動建索引）
• Numeric Types、Monetary Types、Character Types、Date/Time Types
• Mathematical Functions（round 的進位規則）
• Sequence Functions（不保證連號、ON CONFLICT 會消耗）
• PostgreSQL 18 Release Notes（uuidv7()、skip scan、EXPLAIN 自動含 BUFFERS）
• PostgreSQL 11 Release Notes（加欄位免重寫）
• LIMIT and OFFSET（被略過的列仍要算）
• Multicolumn Indexes、Index-Only Scans
• SELECT（CTE 併入、SKIP LOCKED）
• Using EXPLAIN、EXPLAIN
• Explicit Locking（鎖模式、死結、一致的取鎖順序、無限期等待）
• Transaction Isolation（READ COMMITTED 下的重新判斷）
• Serialization Failure Handling（40001、40P01、重試整筆交易）
• Client Connection Defaults（四種逾時）
• Lock Management（deadlock_timeout）
• PREPARE、Query Planning（前 5 次、plan_cache_mode）
• CREATE STATISTICS
• Vacuuming、Routine Vacuuming（門檻、回捲、空間不還、VACUUM FULL）
• ALTER TABLE（鎖等級、NOT VALID、SET NOT NULL 略過掃描）
• Resource Consumption（work_mem）

PostgreSQL 原始碼（REL_18_STABLE）

• pg_proc.dat（每個函式的 LEAKPROOF 與揮發性標記）
• indxpath.c、restrictinfo.c（索引條件的安全檢查）
• clauses.c（列比較逐欄判斷）
• nbtsplitloc.c（_bt_afternewitemoff：局部遞增的分裂最佳化與寬度限制）

PostgreSQL 郵件論壇與第三方（非官方手冊）

• pgsql-bugs：BUG #18544、SET LOCAL 後變數不會變回未定義
• GoCardless：Zero-downtime Postgres migrations（鎖排隊，本文另外實測）
• PGDay Lowlands 2025：Anatomy of Table-Level Locks

AWS

• Prescriptive Guidance：RLS 建議
• Multi-tenant data isolation with PostgreSQL RLS
• Planning I/O in Amazon Aurora
• Amazon Aurora storage
• Manage long-running read queries on Aurora PostgreSQL
• Replication with Aurora PostgreSQL、Aurora Replicas
• Working with autovacuum on Aurora PostgreSQL
• Query Plan Management
• CloudWatch Database Insights
• Slow SQL
• Aurora PostgreSQL 等待事件調校
• Managing Aurora PostgreSQL（連線、閒置連線）
• Performance and scaling for Aurora serverless
• How Aurora serverless works
• Scaling to Zero ACUs
• Blue/Green Deployments 的考量
• Aurora PostgreSQL 擴充功能版本
• Avoiding pinning an RDS Proxy（釘住條件原文）

Npgsql

• Connection String Parameters（各項預設值）
• Performance（連線重設、DISCARD ALL）
• Prepared Statements
• Basic Usage（NpgsqlBatch）
• COPY（BeginBinaryImport）
• Failover and Load Balancing
• EF Core：其他（EnableRetryOnFailure）
• NpgsqlConnector.cs（重設指令）

.NET

• Math.Round、Guid.CreateVersion7