PostgreSQL

現在 code 都讓 AI 寫了，這種判斷它靠得住嗎？ 你在資料庫改了一筆設定——權限、feature flag、某個閾值——接著要決定：改完到底要不要重啟服務才生效？ 放在以前，你會憑經驗猜：保守派一律重啟（常常多此一舉、白白製造一次中斷），樂觀派賭它即時生效（結果改半天前端還吃舊行為，debug 一小時才發現要重啟）。但現在多了一個選項，也是大多數人實際在做的——直接問 AI。於是真正的問題變成：這種「要不要重啟」的判斷，AI 答得對嗎？ AI 會怎麼判斷——而且為什麼常常自信地答錯 先說結論：這題剛好是 AI 最容易出錯的類型，而且會錯得很有自信。 AI 寫 code 的本質，是從訓練資料的 pattern 推測最可能的答案。而「改設定要重啟」在無數系統裡都成立，於是它傾向很篤定地叫你重新部署，卻沒去確認你眼前這份程式碼到底是 live 讀還是快取。版本差異更是重災區——同一個框架舊版快取、新版改成 live 讀，AI 常常混為一談，給你一個「看起來很對」的錯答案。 問題的本質其實沒變，只是換了位置：從前要自己判斷，現在要判斷「AI 的判斷對不對」。而要驗證它、或反過來把它導對，你得先有一把尺——一條不靠經驗、可以拿原始碼直接對答案的準則。 那把尺：即時讀，還是啟動時快取？ 決定「改完要不要重啟」的，從來不是設定存在哪裡，而是程式什麼時候去讀它： 讀取時機 改完是否即時生效 典型例子 每個請求即時讀（per-request live read） ✅ 即時，不必重啟 每次查 DB 的權限、即時拉的 feature flag 啟動時載入記憶體後快取（boot / in-memory cache） ❌ 必須重啟或等過期 bootstrap 載入的設定、process 內的計數器 換句話說：改 DB 要不要重啟，等於問「這個值是 live 讀還是被快取了」。把這句話記住，後面所有案例都是它的推論。 麻煩的是，框架很少在文件裡明講某個值屬於哪一類，AI 也答不準。所以正確的態度不是查文件、更不是憑經驗猜，而是翻原始碼，看那個值是在「請求路徑」上被讀，還是在「啟動路徑」上被讀。下面用一正一反兩個真實案例，把這把尺磨利。 實例一：Strapi 權限「改 DB 即刻生效」 需求很單純：把兩個 content-type（就叫它 article 與 category）的 CUD（Create / Update / Delete，建立／更新／刪除）權限，授給幾個自訂角色。Strapi（一個 Node.js 的 headless CMS）的權限存在資料庫的 up_permissions 表，所以最直接的做法就是下 SQL 把對應的 grant 寫進去。 ...

前言：帳密明明正確，卻回 500 某天收到回報：使用者從手機點開官網登入，帳號密碼都對，卻跳出 Internal Server Error。換其他瀏覽器再登入就成功了。 「帳密正確卻 500」這種錯誤特別惱人，因為它不是身分驗證的問題，而是驗證通過之後才出事。本文記錄怎麼從一行日誌追到根因，以及背後三個值得每個後端工程師記住的設計教訓。 從日誌追根因：三條線索 先分清楚登入失敗的兩種回應：帳密錯誤會回 400 Invalid identifier or password；而這次是 500。光這一點就暗示——帳密其實是對的，問題出在登入流程的後半段。 線索一：500 只在帳密正確時出現 撈出該帳號當天的登入紀錄，發現 500 全部集中在某個時段，之後突然出現一次成功，再之後才是幾筆「帳密錯誤」的 400。換句話說，那串 500 本身就證明了帳密一直是對的——錯的不是驗證。 線索二：那行 PostgreSQL 錯誤訊息 日誌裡每筆 500 都附帶同一句資料庫錯誤： insert into "refresh_tokens" (..., "user_agent") values (...) - value too long for type character varying(255) 真相浮現：登入驗證通過後，後端要寫一筆 refresh token 進資料庫，其中 user_agent 欄位是 varchar(255)，而這次要寫入的值超過 255 字元，PostgreSQL 直接拒絕，未被攔截的例外往上冒成了 500。 線索三：為什麼有時成功、有時失敗 成功那次寫進資料庫的 user_agent 長度是 128；失敗那幾次的值都超過 255。差別就在 User-Agent 字串的長度——而它由「使用者用什麼瀏覽器」決定。 根本原因：varchar(255) 塞不下 in-app 瀏覽器的 UA 寫入 refresh_tokens 的欄位中，token 是固定長度的隨機字串、expires_at 是時間、device_type 是短列舉、ip_address 也很短。唯一長度會劇烈變動、且可能爆掉的，只有 user_agent。 ...

引言:當業務主表需要翻轉 某個 SaaS 系統長期以「客戶資料表」為核心:所有訂單、文件、操作紀錄都用客戶 ID 當外鍵。但這個客戶表的資料來源是外部 POS 系統匯入,每天同步幾百筆,schema 由廠商定義。 業務發展後問題浮現:自己 SaaS 的會員表(users)才是真正的「人」 — 有登入、有偏好、有應用內行為。新功能(個人化推薦、訂閱管理、社交綁定)都需要以 users 為主軸。 於是有了一個經典的 schema migration 需求:主表翻轉(primary table pivot)。把業務邏輯的中心從 customers(外部 POS 匯入)轉到 users(SaaS 自家會員),但歷史資料、新進資料、系統相依、回滾風險全部都要顧到。 名詞解釋 開始拆解之前,定義幾個會反覆出現的詞: 詞 定義 主表翻轉(Primary table pivot) 業務主要 entity 從表 A 改成表 B Dual-write 寫入時同時寫舊欄位 + 新欄位,回滾安全 Partial cut-over 分階段切換,read 跟 write 不同步切 Hard cut-over(stop-the-world) 一次切完,downtime 短但 risk 大 Backfill 歷史資料補齊新欄位的 batch update Idempotent migration 重跑無副作用,cron / retry 安全 DISTINCT ON PostgreSQL 專屬去重 syntax,搭 ORDER BY 取每組第一筆 Pseudo entity 為了統一查詢介面而建的「假」實體 Link table ORM 多對多 join 表(user_id + entity_id) 為什麼選 dual-write 而非 stop-the-world 最直接的搬家方式是「stop-the-world cut-over」:選一個維護窗口,停寫入、跑 batch script、改完所有 reference、開機。但這個 SaaS 的條件不允許: ...

Symptom: A Relation Everyone Believes Is Empty A document management print preview kept rendering “Uploader: —” for every report. The database had the data. The API returned HTTP 200 OK. Yet the uploadedBy relation came back as null, with no error or warning anywhere. Users assumed reports had no uploader assigned. Authors assumed the UI was broken. Nobody suspected the API, because it was perfectly silent. Where the Bug Lives in the Stack Before the curl session, it helps to fix where the failure happens: ...

問題現象：登入成功卻被拒於門外 最近在 Staging 環境遇到一個詭異的問題：使用者登入成功，拿到了有效的 JWT Token，但存取任何需要認證的 API 都回傳 401 Unauthorized。 # 登入成功，拿到 token POST /api/auth/local → 200 OK { "jwt": "eyJhbGc...xxxxx...your-jwt-token", "user": { "id": 1001, "email": "[email protected]" } } # 但存取個人資料失敗 GET /api/users/me → 401 Unauthorized Token 驗證通過、使用者存在、帳號未被封鎖。問題到底在哪？ 根本原因：遺失的 Link Table 經過一番追查，發現問題出在資料庫同步時漏掉了關聯表（Link Table）。 什麼是 Link Table？ 在關聯式資料庫中，多對多關係需要透過中間表來建立。這個中間表就是 Link Table（也稱為 Junction Table、Join Table、或 Pivot Table）。 erDiagram users ||--o{ users_roles_lnk : has roles ||--o{ users_roles_lnk : assigned_to users { int id PK string email string password boolean confirmed } roles { int id PK string name string type } users_roles_lnk { int user_id FK int role_id FK int user_ord } 使用者與角色的關係： ...

接手專案，先看帳單 因為老闆信用卡到期了要換新卡，我順便看了一下 AWS 帳單金額，發現比預期高。之前詢問外包商技術長（已離職），得到的回覆是：「服務都已經從新加坡遷移到台北了，除了 S3 有保留做備份，其他都刪除了。」 身為工程師，最不能接受的就是「應該是這樣」。我決定親自盤點。 名詞解釋 在繼續之前，先解釋一下會提到的 AWS 服務： 服務 說明 費用特性 S3 (Simple Storage Service) 物件儲存服務，用來存放檔案、圖片、影片 按儲存容量和請求次數計費 NAT Gateway 讓私有子網路的資源能存取網際網路 按小時計費，即使沒流量也要錢 Elastic IP 固定的公開 IP 位址 使用中免費，未關聯則收費 VPC (Virtual Private Cloud) 虛擬私有網路，隔離你的雲端資源 VPC 本身免費，但相關資源收費 Network Load Balancer 負載平衡器，分散流量到多台伺服器 按小時和處理的資料量計費 ECR (Elastic Container Registry) Docker 映像檔儲存庫 按儲存容量計費 重點是：有些資源即使沒有流量，只要存在就會收費。NAT Gateway 和未關聯的 Elastic IP 就是典型的「隱形殺手」。 盤點遺留資源 # 檢查 EKS 叢集（Kubernetes 服務） aws eks list-clusters --region ap-southeast-1 # 結果：空的 ✓ # 檢查 RDS（資料庫） aws rds describe-db-instances --region ap-southeast-1 # 結果：空的 ✓ # 檢查 NAT Gateway aws ec2 describe-nat-gateways --region ap-southeast-1 \ --filter "Name=state,Values=available" # 結果：2 個還在跑 完整盤點結果： ...

起因：老闆想省錢 「Staging 環境平常沒人用，每個月還要燒 $45-60 美金，能不能想辦法省一點？」 Staging 環境的成本來自兩個地方：RDS 資料庫（約 $15-20/月）和 EKS 節點（約 $30-40/月）。既然平常沒在用，我想到了一個方案：不用的時候關掉，需要的時候再打開。 於是我寫了兩個腳本： staging-start.sh：啟動 RDS、擴充節點、部署應用 staging-stop.sh：刪除部署、縮減節點、停止 RDS # staging-stop.sh 核心邏輯 kubectl delete deployment app-strapi-stg app-web-stg aws eks update-nodegroup-config \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --scaling-config minSize=0,maxSize=2,desiredSize=1 # 從 2 縮到 1 aws rds stop-db-instance --db-instance-identifier my-stg-rds 看起來很合理，但這裡有個問題：Production 和 Staging 共用同一個 nodegroup。 踩坑：AWS 隨機選擇刪除節點 執行 staging-stop.sh 縮減節點時，AWS 會隨機選擇要終止哪個節點。當時的配置： 節點 A：運行 Production pods 節點 B：運行 Staging pods 我期望刪除節點 B，但 AWS 選了節點 A。Production pods 被強制遷移，觸發了重新調度。 ...

「奇怪，我明明刪了 52 萬筆資料，為什麼資料表還是 207MB？」 這是我今天在清理資料庫時遇到的真實情況。如果你也曾經困惑過這個問題，這篇文章會告訴你背後的原因。 事情是這樣的 專案的 user_notifications 資料表累積了幾十萬筆推播通知記錄，佔用了 207MB 空間。為了控制資料庫大小，我寫了一個 cron job 來清理超過 7 天的舊資料： // 刪除 7 天前的通知 const sevenDaysAgo = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000); await strapi.db.query('api::user-notification.user-notification').deleteMany({ where: { createdAt: { $lt: sevenDaysAgo.toISOString() } }, }); 執行結果很漂亮： [Cleanup] Successfully deleted 521604 old user notifications 刪除了 521,604 筆！只剩下約 2 萬筆近期資料。 但當我打開 DBeaver 檢查時… 207MB？資料都刪了，空間怎麼沒變？ 為什麼會這樣？理解 PostgreSQL 的 MVCC 這不是 bug，而是 PostgreSQL 的設計特性。 DELETE 不是真的刪除 PostgreSQL 使用 MVCC（Multi-Version Concurrency Control） 來處理並發交易。當你執行 DELETE 時，PostgreSQL 不會真的把資料從磁碟上移除，而是： 將該行標記為「已刪除」（稱為 dead tuple） 保留原始資料，直到沒有任何交易需要參照它 新的查詢看不到這些行，但它們仍佔用磁碟空間 為什麼要這樣設計？ 效能考量：標記刪除比實際移除資料快非常多 並發安全：其他正在執行的 transaction 可能還需要看到舊版本 ACID 保證：確保 transaction isolation 不處理會怎樣？ ...

「老闆，用戶的解鎖記錄全不見了！」「快把舊資料拉出來灌回去！」在緊急狀況下，我沒想太多就照做了。然後，我不小心埋下了一顆定時炸彈… 🔥 第一幕：災難降臨 2025 年 11 月某日，上午 10:30 Slack 突然炸開： 💬 同事：「完蛋了…我剛剛不小心部署到舊的 commit…」 💬 QA：「欸！為什麼使用者的動畫解鎖記錄都不見了？」 💬 使用者：「我昨天才花金幣解鎖的動畫怎麼不見了？」 💬 老闆：「@所有人 立刻確認影響範圍！」 我打開資料庫一看： SELECT COUNT(*) FROM user_unlocked_animations; -- 結果: 0 😱 所有用戶的解鎖記錄全部消失！ 原因：同事不小心部署了一個舊的 Strapi commit，那個版本的 database migration 把 user_unlocked_animations 相關的表全部清空了。 ⚡ 第二幕：老闆的緊急命令 💬 老闆：「快！把之前的用戶解鎖記錄拉出來，灌回現在的資料庫！」 我心裡想：「舊資料插回去，新資料又同時在進來…會不會有問題？」 但老闆在等，使用者在抱怨，沒時間多想，先恢復資料再說。 緊急恢復資料 // 從備份拉出資料，直接插入（包含原始的 ID） blablablabla } // ⚠️ 直接指定了 id，但沒想到要更新 sequence... 執行完畢： ✅ 資料恢復完成！ QA 測試：「使用者的解鎖記錄都回來了！」 眾人鬆了一口氣。 💣 第三幕：24 小時後，炸彈引爆 隔天下午 💬 客服：「有使用者回報說無法解鎖動畫!!!」 💬 使用者：「我有 3 個金幣，想解鎖動畫，但一直顯示錯誤！金幣被扣了但動畫沒解鎖！」 ...

前言 在現代雲端架構中，資料庫通常部署在受保護的私有網路環境（Private Subnet）中，以提升安全性。AWS RDS（Relational Database Service）作為主流的托管資料庫服務，提供了多種連線方式，但對於初學者來說，如何在不同環境（本機、Docker、Kubernetes）中正確連線到 RDS 往往充滿挑戰。 這篇文章將深入探討： AWS RDS 網路架構：公有子網 vs 私有子網的差異 直接連線方式：當 RDS 設為 Publicly Accessible 時 SSH 隧道（SSH Tunneling）：透過 Bastion Host 連線私有 RDS 容器環境連線：在 Docker 和 Kubernetes Pod 中使用 psql psql 完整命令參考：從基礎查詢到進階操作 安全最佳實踐：如何保護資料庫連線與憑證 常見問題排查：連線失敗的系統化診斷方法 無論你是在本機開發、容器化部署、或是 Kubernetes 叢集中操作，這篇文章都能幫助你建立安全可靠的資料庫連線。 AWS RDS 網路架構概覽 在開始連線之前，我們需要理解 AWS RDS 的網路架構。RDS 實例可以部署在不同的網路環境中，每種配置都有不同的連線方式和安全考量。 公有子網 vs 私有子網 graph TB subgraph "AWS VPC" subgraph "Public Subnet (10.0.1.0/24)" IGW[Internet Gateway] Bastion[Bastion Host<br/>EC2 Instance] RDS_Public[RDS PostgreSQL<br/>Publicly Accessible: Yes<br/>10.0.1.100] end subgraph "Private Subnet (10.0.2.0/24)" RDS_Private[RDS PostgreSQL<br/>Publicly Accessible: No<br/>10.0.2.100] App[Application Servers<br/>ECS/EKS Pods] end subgraph "Security" SG_RDS[Security Group: RDS<br/>Inbound: 5432 from App] SG_Bastion[Security Group: Bastion<br/>Inbound: 22 from MyIP] end end subgraph "外部網路" Developer[開發者本機] Web[網際網路] end Web --> IGW Developer -->|SSH Port 22| Bastion Developer -->|psql Port 5432<br/>⚠️ 不安全| RDS_Public Bastion -.->|SSH Tunnel| RDS_Private App -->|psql Port 5432| RDS_Private RDS_Public -.->|套用| SG_RDS RDS_Private -.->|套用| SG_RDS Bastion -.->|套用| SG_Bastion style RDS_Public fill:#ffe1e1 style RDS_Private fill:#e1ffe1 style Bastion fill:#e1f5ff style Developer fill:#fff3e1 兩種部署方式的比較 特性 公有子網 (Publicly Accessible) 私有子網 (Private) 直接連線 ✅ 可以從網際網路直接連線 ❌ 無法直接連線 安全性 ⚠️ 較低，暴露在公網 ✅ 高，完全隔離 連線方式 psql 直連 需要 Bastion Host / VPN 適用場景 開發測試環境 生產環境（推薦） 成本 RDS 費用 RDS + Bastion Host 費用 維護複雜度 低 中等（需管理 Bastion） 最佳實踐： ...