DBA 參考指南
使用規則：下列命令為穩定且廣為人知的格式。不同版本與版本別（涉及授權！）的行為可能有所不同 - 若某一行標示「請根據您的版本驗證」，請在依賴該命令前，查閱該廠商針對特定發行版本的官方文件。切勿在未建立變更記錄的情況下，於生產環境中執行任何會修改資料的診斷陳述式。
1. 引擎快速比較
| 主題 | Oracle | PostgreSQL | SQL Server | Db2 LUW | MySQL / MariaDB (InnoDB) |
|---|
| 並行模型 | MVCC (undo)；讀取從不阻塞寫入 | MVCC (資料表中的行版本；VACUUM) | 預設使用鎖定；若啟用 RCSI/快照隔離則為 MVCC | 鎖定；若啟用 CUR_COMMIT 則為「目前提交」讀取 | MVCC (undo) + REPEATABLE READ（預設）中的 next-key/gap 鎖定 |
| 交易性 DDL | 否（前後隱含提交） | 是（除了 CREATE INDEX CONCURRENTLY、CREATE DATABASE、VACUUM 等） | 大部分 DDL 為是 | 大部分 DDL 為是（請根據陳述式驗證） | 否（隱含提交；MySQL 8 的 DDL 僅為每個陳述式原子性） |
| 鎖定升級 | 從不 | 從不 | 是（資料列/頁面 -> 資料表，每個陳述式每個物件約 5000 個鎖定） | 是（LOCKLIST/MAXLOCKS） | 否（但有 gap 鎖定） |
| 查詢統計 | AWR/ASH (Diagnostics Pack), Statspack | pg_stat_statements | Query Store, DMVs | MON_GET_* 資料表函數 | performance_schema、sys schema、慢查詢日誌 |
| 工作階段鎖定逾時 | ALTER SESSION SET DDL_LOCK_TIMEOUT = 30; (DDL, 秒) | SET lock_timeout = '5s'; | SET LOCK_TIMEOUT 5000; (毫秒) | SET CURRENT LOCK TIMEOUT 30; (秒) | SET SESSION lock_wait_timeout = 30; (中繼資料鎖定) + innodb_lock_wait_timeout (資料列鎖定) |
2. 效能診斷
方法：(1) 定義症狀（單一查詢、單一時間區間、整個執行個體）；(2) 在調整 SQL 之前，先檢視等待/時間模型；(3) 取得實際執行計畫（而非僅估計的）；(4) 比較估計值與實際資料列數 - 基數估計錯誤是常見的根本原因（過時的統計資料、偏斜、相關謂詞、參數探測/繫結窺視）；(5) 一次變更一項，然後進行測量。
Oracle
- 估計計畫：
EXPLAIN PLAN FOR <stmt>; 然後 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
- 實際計畫：使用
/*+ GATHER_PLAN_STATISTICS */ 提示執行，然後 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>', NULL, 'ALLSTATS LAST'));
- AWR/ASH/ADDM (
@?/rdbms/admin/awrrpt.sql、ashrpt.sql、addmrpt.sql、V$ACTIVE_SESSION_HISTORY、DBA_HIST_*) 需要 Diagnostics Pack (Enterprise Edition)；SQL Monitor 與 SQL Tuning Advisor 需要 Tuning Pack。請檢查 CONTROL_MANAGEMENT_PACK_ACCESS。若無授權：請使用 Statspack。
- 即時等待：
V$SESSION (event、wait_class、sql_id、blocking_session)、V$SYSTEM_EVENT、V$SQL / V$SQLSTATS。
- 常見等待：
db file sequential read (單一區塊，索引存取)、db file scattered read / direct path read (完整掃描)、log file sync (提交頻率 / 重做 I/O)、enq: TX - row lock contention (應用程式鎖定)、enq: TM - contention (通常是未索引的外鍵)、latch: cache buffers chains (熱區塊)、gc * (RAC 互連)。
- 計畫穩定性：SQL Plan Management (基準線)；SQL profile 需要 Tuning Pack。
PostgreSQL
EXPLAIN (ANALYZE, BUFFERS) <stmt>; - ANALYZE 會執行該陳述式：請將 DML 包裝在 BEGIN; ... ROLLBACK; 中。pg_stat_statements (需要 shared_preload_libraries)：按 total_exec_time 排序的熱門 SQL（欄位名稱在 PG13 中已變更為 total_exec_time、mean_exec_time）。
SELECT queryid, calls, round(total_exec_time) total_ms, round(mean_exec_time::numeric,1) mean_ms, rows, left(query,80) FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20;- 即時：
pg_stat_activity (state、wait_event_type、wait_event、xact_start、query)；idle in transaction 的工作階段會持有鎖定並阻塞 VACUUM。
auto_explain 模組可將慢查詢計畫記錄於日誌中；track_io_timing = on 可啟用 I/O 時間記錄。- 健康狀態：
pg_stat_user_tables (seq_scan、n_dead_tup、last_autovacuum、last_autoanalyze)；膨脹；交易 ID 環繞：SELECT datname, age(datfrozenxid) FROM pg_database;。
- 終止：先使用
pg_cancel_backend(pid) (查詢)，然後使用 pg_terminate_backend(pid) (工作階段)。
SQL Server
- 實際計畫：SSMS 中的「包含實際執行計畫」或
SET STATISTICS XML ON;；使用 SET STATISTICS IO, TIME ON; 檢視讀取次數/CPU。
- Query Store (2016 以上版本；2022 版本預設為新資料庫啟用)：
sys.query_store_query、sys.query_store_query_text、sys.query_store_plan、sys.query_store_runtime_stats、sys.query_store_wait_stats (2017 以上版本)；回歸 -> 計畫強制 EXEC sp_query_store_force_plan @query_id = <q>, @plan_id = <p>;。
- DMVs：
sys.dm_exec_requests (wait_type、blocking_session_id)、sys.dm_os_wait_stats、sys.dm_exec_query_stats + CROSS APPLY sys.dm_exec_sql_text(sql_handle) + sys.dm_exec_query_plan(plan_handle)。
- 常見等待：
PAGEIOLATCH_* (資料讀取)、LCK_M_* (阻塞)、WRITELOG (日誌 I/O / 提交率)、CXPACKET/CXCONSUMER (平行處理 - 檢查 MAXDOP/成本閾值)、SOS_SCHEDULER_YIELD (CPU)、ASYNC_NETWORK_IO (用戶端未取用結果)、RESOURCE_SEMAPHORE (記憶體授權)。
- 參數探測：比較每個參數的計畫；選項包括
OPTION (RECOMPILE)、OPTIMIZE FOR、Query Store 提示 (2022) - 請依據情況選擇。
- 擴充事件；
system_health 工作階段會保留最近的死結圖形。
Db2 LUW
- 解釋計畫：建立解釋資料表 (
SYSPROC.SYSINSTALLOBJECTS 或 EXPLAIN.DDL)、EXPLAIN PLAN FOR <stmt>、使用 db2exfmt -d <DB> -1 -o plan.txt 格式化；快速檢視 db2expln。
- 監控資料表函數：
MON_GET_PKG_CACHE_STMT (熱門 SQL: STMT_EXEC_TIME、NUM_EXECUTIONS、ROWS_READ)、MON_GET_CONNECTION、MON_GET_ACTIVITY、MON_GET_TABLE、MON_GET_BUFFERPOOL。
- 鎖定：
SYSIBMADM.MON_LOCKWAITS、db2pd -db <DB> -wlocks、db2pd -db <DB> -locks。
- 統計資料：
RUNSTATS ON TABLE <SCHEMA>.<TABLE> WITH DISTRIBUTION AND DETAILED INDEXES ALL; - 使用 REORGCHK 評估重組需求；使用 db2advis 取得索引建議。
MySQL / MariaDB
EXPLAIN <stmt>；實際計畫：MySQL 8.0.18 以上版本 EXPLAIN ANALYZE <stmt>；MariaDB ANALYZE <stmt> (兩者都會執行該陳述式)。- 熱門 SQL：
sys.statement_analysis、performance_schema.events_statements_summary_by_digest；慢查詢日誌 (slow_query_log、long_query_time) + pt-query-digest。
- InnoDB：
SHOW ENGINE INNODB STATUS\G (最新的死結、歷史清單長度)、information_schema.INNODB_TRX、sys.innodb_lock_waits；MySQL 8：performance_schema.data_locks / data_lock_waits；MariaDB：information_schema.INNODB_LOCKS / INNODB_LOCK_WAITS 以及 METADATA_LOCK_INFO 外掛程式；MySQL 中繼資料鎖定：performance_schema.metadata_locks。
3. 鎖定與並行 - 陷阱
| 引擎 | 陷阱 | 緩解措施 |
|---|
| 全部 | 長時間交易 + DDL：DDL 會等待，且之後的每個查詢都會在其後排隊 | 對 DDL 設定較短的鎖定逾時、使用重試迴圈、在無長時間交易時執行；執行前檢查（活躍工作階段） |
| Oracle | 未索引的外鍵 -> 當父資料列被刪除 / PK 更新時，在子資料表上產生的 TM 鎖定 | 為 FK 欄位建立索引 |
| Oracle | 在忙碌物件上的 DDL 失敗，出現 ORA-00054 | DDL_LOCK_TIMEOUT；線上變體（CREATE INDEX ... ONLINE、ALTER TABLE ... MOVE ONLINE 12.2 以上版本、DBMS_REDEFINITION）- 全部僅限 Enterprise Edition (SE2 不適用) |
| Oracle | 在開啟游標的迴圈內提交 -> ORA-01555 snapshot too old | 按鍵值/rowid 範圍進行區塊處理（DBMS_PARALLEL_EXECUTE），設定足夠大的 undo 保留空間 |
| PostgreSQL | 大多數 ALTER TABLE 會取得 ACCESS EXCLUSIVE 鎖定；等待它會阻塞所有讀取 | SET lock_timeout；CREATE INDEX CONCURRENTLY；FK/CHECK 使用 NOT VALID 然後 VALIDATE CONSTRAINT |
| PostgreSQL | 變更資料行類型會重寫整個資料表（除了安全的案例，例如增加 varchar 長度） | 使用新資料行 + 回填進行擴展/收縮 |
| PostgreSQL | idle in transaction 的工作階段 | idle_in_transaction_session_timeout，修復應用程式 |
| SQL Server | 在預設的 READ COMMITTED 隔離層級下，讀取會阻塞寫入 | 評估 READ_COMMITTED_SNAPSHOT ON（會影響 tempdb 版本存放區；請測試） |
| SQL Server | 大型 DML 會將鎖定升級至資料表層級 | 批次處理低於約 5000 筆資料列；謹慎使用 ALTER TABLE ... SET (LOCK_ESCALATION = ...) |
| SQL Server | 使用 NOLOCK 作為「修正」方法 | 髒讀、遺失/重複資料列 - 在審查中拒絕 |
| Db2 | LOCKTIMEOUT = -1 (永遠等待) 為預設值 | 在發佈工作階段中設定 CURRENT LOCK TIMEOUT |
| Db2 | ALTER TABLE ... DROP COLUMN、大多數 ALTER COLUMN SET DATA TYPE、SET NOT NULL/DROP NOT NULL 會將資料列組織的資料表置於重新組織擱置 (reorg-pending) 狀態 (SQLSTATE 57007)：在執行 REORG TABLE 之前，僅允許掃描、DROP/RENAME/TRUNCATE 以及大多數其他 ALTER 操作；此類操作最多 31 個工作單元後，REORG 變為強制性 | 在時間視窗內規劃 REORG TABLE；檢查 SYSIBMADM.ADMINTABINFO 中的 REORG_PENDING / NUM_REORG_REC_ALTERS |
| MySQL | 中繼資料鎖定 (MDL) 等待：DDL 被一個開啟的交易阻塞，進而阻塞所有人 | 在發佈工作階段中設定較低的 lock_wait_timeout；終止長時間處於閒置狀態的交易 |
| MySQL | 線上 DDL 會默默地回退為資料表複製 | 始終使用 ALGORITHM=INSTANT (或 INPLACE) 搭配 LOCK=NONE`，使其在無法使用時報錯；或使用 gh-ost / pt-online-schema-change |
| MySQL | 在 REPEATABLE READ 隔離層級下，範圍更新會產生 Gap/next-key 鎖定 | 為謂詞建立索引；在可接受的情況下考慮使用 READ COMMITTED |
死結：始終是設計問題（不一致的存取順序、缺少索引）。擷取：Oracle trace 檔案 / alert 日誌 (ORA-00060)、PostgreSQL 日誌 (log_lock_waits = on 可記錄超過 deadlock_timeout 的等待)、SQL Server system_health XE、Db2 鎖定事件監控器、MySQL innodb_print_all_deadlocks。
4. 高可用性 (HA) / 災難復原 (DR)
| 引擎 | 本地 HA | DR / 複本 | 關鍵操作與檢查 |
|---|
| Oracle | RAC (共享儲存、主動-主動、需要額外授權) | Data Guard 實體待命 (重做套用)；Active Data Guard = 開啟唯讀並套用（需要額外授權） | 保護模式：Maximum Performance (ASYNC, 預設)、Maximum Availability (SYNC, 失敗時降級)、Maximum Protection (SYNC, 若無待命則主要停止)。Broker dgmgrl：SHOW CONFIGURATION;、VALIDATE DATABASE <stby>;、SWITCHOVER TO <stby>;、FAILOVER TO <stby>;。延遲：V$DATAGUARD_STATS。主要資料庫啟用 FORCE LOGGING。Fast-Start Failover 需要一個觀察者（理想情況下在第三個站點）。 |
| PostgreSQL | Patroni (DCS: etcd/Consul/ZooKeeper) + HAProxy/VIP | 串流複製 (實體, WAL)；邏輯複製 (發行/訂閱, PG10 以上版本) | pg_stat_replication (sent_lsn、write_lsn、flush_lsn、replay_lsn)、pg_is_in_recovery()、pg_promote() (PG12 以上版本)。同步：synchronous_standby_names + synchronous_commit。複製槽若複本離線會保留 WAL -> 磁碟空間耗盡：監控，使用 max_slot_wal_keep_size (PG13 以上版本) 設定上限。Patroni：patronictl -c <cfg> list / switchover / failover；供負載平衡器使用的 REST 健康狀態端點 (/primary、/replica)。邏輯複製不複製 DDL 或序列值（截至 PG 18 版）：先在訂閱者端套用新增的結構描述變更，並在容錯移轉至訂閱者前重設序列。 |
| SQL Server | 容錯移轉叢集執行個體 (共享儲存, WSFC) | Always On 可用性群組 (WSFC 或 Linux 上的 Pacemaker)；日誌傳送 | 只有同步提交的複本之間才能進行自動容錯移轉。供用戶端使用的接聽程式 (MultiSubnetFailover=True)。登入、Agent 作業、連結伺服器、認證不會被複製 (包含的可用性群組，SQL Server 2022 Enterprise，有幫助)。完整的 AG 需要 Enterprise 版本；Standard Edition 上的 Basic AG (1 個資料庫，2 個複本)。檢查 sys.dm_hadr_database_replica_states。計劃性容錯移轉：在目標同步次要複本上執行 ALTER AVAILABILITY GROUP [<AG>] FAILOVER;。可讀取的次要複本有授權方面的影響。 |
| Db2 LUW | pureScale (主動-主動) 或 HADR + Pacemaker/TSA 自動化 | HADR (最多 3 個待命，HADR_TARGET_LIST) | HADR_SYNCMODE：SYNC、NEARSYNC、ASYNC、SUPERASYNC。監控 db2pd -db <DB> -hadr 或 MON_GET_HADR。在待命端進行角色切換：TAKEOVER HADR ON DATABASE <DB> (使用 BY FORCE 進行容錯移轉)。透過 DB2_HADR_ROS 在待命端進行讀取（有限制）。 |
| MySQL / MariaDB | InnoDB Cluster (Group Replication + MySQL Router)；Galera (MariaDB) | 非同步 / 半同步複製，基於 GTID | SHOW REPLICA STATUS (MySQL 8.0.22 以上版本；MariaDB 10.5.1 以上版本接受 REPLICA 作為 SLAVE 的同義詞；舊版本：SHOW SLAVE STATUS)。監控複製延遲與錯誤的 GTID；Galera 需要主要元件法定人數（3 個節點或仲裁者）。 |
設計規則：在選擇同步/非同步複製前，先定義每個應用程式的 RPO/RTO；至少每年進行一次 DR 測試並記錄結果（DORA 要求金融機構進行 ICT 持續性測試）；用戶端必須能透明地重新連線（包含多主機/接聽程式/SCAN 的連線字串、重試邏輯）；監控延遲並發出警報；防護腦裂（法定人數、圍籬、位於第三站點的觀察者/見證者）。
5. 備份、還原、PITR
| 引擎 | 完整 / 增量 | PITR | 驗證 |
|---|
| Oracle (RMAN) | BACKUP DATABASE PLUS ARCHIVELOG; 增量等級 0/1；CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS; | 需要 ARCHIVELOG 模式。請使用 RUN { SET UNTIL TIME "TO_DATE('2026-10-01 12:00','YYYY-MM-DD HH24:MI')"; RESTORE DATABASE; RECOVER DATABASE; } 然後 ALTER DATABASE OPEN RESETLOGS; | RESTORE DATABASE VALIDATE;、CROSSCHECK BACKUP;、LIST BACKUP SUMMARY;、REPORT NEED BACKUP;、DELETE OBSOLETE; |
| PostgreSQL | pg_basebackup -D <dir> -Ft -z -X stream -P；pgBackRest --type=full / diff / incr backup；Barman。pg_dump 僅為邏輯備份（無 PITR） | 需要 WAL 歸檔 (archive_mode、archive_command)；還原基礎備份 + restore_command + recovery_target_time + recovery.signal (PG12 以上版本)。pgBackRest：pgbackrest --stanza=<s> --type=time "--target=2026-10-01 12:00:00+02" restore | pgbackrest --stanza=<s> check、pgbackrest --stanza=<s> info；定期進行實際還原測試 |
| SQL Server | 復原模式 FULL；BACKUP DATABASE [<db>] TO DISK = N'<path>' WITH CHECKSUM, COMPRESSION; 差異備份；BACKUP LOG | 還原完整備份 WITH NORECOVERY，然後還原差異備份與日誌備份，最後 WITH RECOVERY。RESTORE DATABASE [<db>] FROM DISK = N'<path>' WITH FILE = 1, NORECOVERY; RESTORE LOG [<db>] FROM DISK = N'<path>' WITH STOPAT = '2026-10-01 12:00:00', RECOVERY; | RESTORE VERIFYONLY FROM DISK = N'<path>' WITH CHECKSUM; |
| Db2 LUW | BACKUP DATABASE <DB> TO <path> WITH 2 BUFFERS BUFFER 1024 PARALLELISM 3 COMPRESS EXCLUDE LOGS WITHOUT PROMPTING; 增量 INCREMENTAL DELTA | db2ckbkp、db2dart / INSPECT；還原測試：db2 RESTORE DATABASE <DB> FROM <path> ... WITHOUT PROMPTING | db2ckbkp <image>；db2dart <DB> /DB |
| MySQL / MariaDB | Percona XtraBackup (xtrabackup --backup --target-dir=<dir>)；mysqldump 僅為邏輯備份；區塊鏈備份 / MariaDB Backup | 需要啟用 log_bin、server_id，以及 GTID (gtid_mode=ON)。mysqlbinlog + --stop-datetime；XtraBackup 配合 --apply-log 與 --copy-back | Percona XtraBackup 配合 --verify=CRC32 |
6. 安全性 / GDPR
原則
- 不要以純文字形式儲存機密資料，不要在應用程式程式碼或設定檔中寫入密碼或連線字串（使用密碼管理員 / vault 來輪換機密資料）。
- 使用最小權限原則：應用程式使用者僅應擁有必要的權限（例如，INSERT/SELECT/UPDATE/DELETE 在特定資料表或角色上，外加必要的執行權限）。
- DDL 操作不應使用應用程式帳戶來執行（應使用特權帳戶）。
- 加密靜態資料（TDE、檔案系統層級加密）。
- 僅對允許存取的使用者授予檢視/資料表/列的權限，以實作行級安全性 (RLS)。
- 稽核誰在何時存取了哪些資料：啟用稽核，特別是可識別個人身分的資料 (PII)、GDPR 相關資料。
金鑰與證書
- 避免以純文字形式儲存密碼至少作為一個原則。使用密碼管理員 / vault 來取得/輪換機密資料。
- 對資料庫連線使用 TLS/SSL：檢查
LISTENER 的 SSL 設定 (ssl_cert、ssl_key、ssl_ca)、pg_hba.conf (主機ssl、用戶端憑證)、ALTER DATABASE ... SET SSL = ON;... 管理員密碼/應用程式密碼應該存放在一個機密儲存庫中。
- MySQL 的
init_connect 可用於為 PII 強制執行 SET SESSION sql_log_bin = 0;。
GDPR 特定事項
- 個人資料應在可行情況下於生產環境外進行假名化/匿名化/遮罩。
- 備份保留期間應符合 GDPR 的資料最小化要求。
- 應在稽核日誌中記錄對 PII 資料的存取，並定期審查。
- 刪除權（被遺忘權）：實作級聯刪除或標記為刪除，並確保備份最終會清除該資料，或使用保留原則來刪除陳舊的備份。
- 遷移至非歐盟地區的資料庫時，需有適當的資料保護協議，如標準契約條款 (SCCs) 或約束性企業規則 (BCRs)。
7. Oracle 遷移至 PostgreSQL 的陷阱
| 陷阱 | 詳細說明 | 解決方案 |
|---|
| 內建函數差異 | SYSDATE (Oracle) -> NOW(), CURRENT_TIMESTAMP (PostgreSQL)；NVL(a, b) -> COALESCE(a, b)；DECODE(a, b, c) -> CASE WHEN a = b THEN c ELSE ... END；層級化查詢 (CONNECT BY) -> 遞迴 CTE (WITH RECURSIVE) | 使用遷移工具（ora2pg、AWS DMS SCT）產生程式碼，但請手動審查其輸出。最好重寫所有查詢。 |
| 空值與排序 | 在 Oracle 中，NULL 值在 ORDER BY ... ASC 中被視為最大值（最後排序）；在 PostgreSQL 中則被視為最小值（首先排序）。 | 使用 ORDER BY ... NULLS LAST (PostgreSQL) 來比照 Oracle 的行為。 |
| 隱含型別轉換 | Oracle 會自動將 VARCHAR2 轉換為 NUMBER（例如：WHERE 1 = '1'）；PostgreSQL 則不會。 | 修正查詢中的資料型別；或建立自訂的隱含轉換，但這通常不是一個好主意。 |
| 序列 | CREATE SEQUENCE ... START WITH 100 在 PostgreSQL 中是可以的，但 CACHE 行為不同；在 Oracle 序列上使用 ALTER TABLE ... ADD GENERATED BY DEFAULT AS IDENTITY；PostgreSQL 的 identity 資料行是自動產生的。 | 在遷移期間重設序列值以符合 Oracle 的當前值。 |
| 觸發程序與遞迴 | Oracle 預設允許 INSERT/UPDATE/DELETE 的觸發程序；PostgreSQL 需要 CREATE CONSTRAINT TRIGGER ... DEFERRABLE INITIALLY DEFERRED 來模擬遞迴。 | 審查觸發程序邏輯，可能將其重寫為 from ... 更容易。 |
| 儲存程序 / PL/SQL | Oracle 使用 PL/SQL；PostgreSQL 使用 PL/pgSQL（類似但不相同）。FORALL 在 PostgreSQL 中不存在。BULK COLLECT 不存在。請使用 RETURN NEXT 或 RETURN QUERY 來模擬管線化函數。 | 需要手動重寫。 |
| Lock 語法 | SELECT ... FOR UPDATE 相似；但 PostgreSQL 不支援 WAIT N（它使用 NOWAIT 和佈林值超時參數）。 | 使用 SELECT ... FOR UPDATE NOWAIT 或在應用程式層級設定 lock_timeout。 |
| 資料類型對應 | NUMBER (Oracle) 應對應到 NUMERIC（在 PostgreSQL 中更精確且更慢）或 INTEGER / BIGINT；VARCHAR2(n) -> VARCHAR(n)；DATE (Oracle) 對應到 TIMESTAMP(0)；CLOB / BLOB -> TEXT / BYTEA。 | 為資料定義一致的資料型別對應。 |
| 索引 | Oracle 的索引可以是基於函數的、位元圖的；PostgreSQL 有部分索引、GiST、GIN、BRIN 索引。CREATE INDEX 語法相似，但選項不同。 | 在遷移過程中重新建立索引。 |
| 交易控制 | Oracle 沒有交易界限（隱含提交）。；PostgreSQL 的每個陳述式都隱含在一個交易中。 | 檢查應用程式的交易邏輯（例如，BEGIN / COMMIT）。 |
8. 發佈指令碼與審查檢查清單
發佈指令碼原則
- 每個指令碼應是冪等的（可安全地重複執行）。
- 使用版本控制管理指令碼（例如，存放於 git，使用 Flyway、Liquibase 或 Alembic 等工具）。
- 在執行 DDL 時，對鎖定與效能影響保持謹慎（避免長時間交易）。
- 在開發/測試/預發環境中測試指令碼，然後才在生產環境中執行。
- 寫入遷移指令碼，而不是一次性修正。
審查檢查清單
9. 進一步資訊
- Oracle：官方文件、Ask TOM、SQL Live、Oracle Base。
- PostgreSQL：官方文件、PostgreSQL Planet、Stack Overflow。
- SQL Server：官方文件、SQL Shack、Brent Ozar 的簡潔指引。
- Db2 LUW：知識中心、IBM 開發人員。
- MySQL / MariaDB：官方文件、Percona 部落格、Planet MySQL。