某專案使用 10 條執行緒並發查詢 Oracle 資料庫（三張表各 500 萬筆，已建索引）。單執行緒查詢 4-6 秒，並發後部分執行緒飆升至 30+ 秒。本文分析根因並給出優化方向。
核心原因分析
1. 資料庫端資源爭用
- 多執行緒同時發送 SQL，Oracle 需分配 PGA、排序區、暫存段等記憶體，若
PGA_AGGREGATE_TARGET 不足，導致大量磁碟排序（TEMP 表空間壓力）。
- 共享游標、Library Cache 鎖競爭（Cursor: pin S wait on X 等待事件）。
- I/O 子系統頻寬飽和：多執行緒同時全表掃描或大量索引範圍掃描，磁碟隨機讀寫延遲暴增。
2. 伺服器硬體限制
若資料庫伺服器為單核或雙核 CPU，多執行緒無法真正並行，反而增加 Context Switch 開銷。回覆中提到「多核才可能發揮提升多線程性能，而且並沒有你想像那麼大」一針見血。
3. 應用端連線池設定不當
- 連線池大小超過資料庫可承載的並發上限（
processes/sessions 參數）。
- 未使用 Statement Caching，導致重複 Hard Parse。
優化策略
- 限制並發度：依 CPU 核心數與 I/O 能力設定合理的連線池大小（如 2×CPU 核心數），避免過度並發。
- SQL 調優：確認執行計畫走索引，避免全表掃描；必要時加 Hint 或改寫 SQL。
- 啟用 Result Cache / 查詢重寫：對重複查詢的靜態資料，使用 Oracle Result Cache 或應用層快取（Redis、Guava Cache）。
- 分區表 / 平行查詢：大表可考慮分區，並開啟 Parallel Query（需 Enterprise Edition）。
- 資料庫參數調整：增大
PGA_AGGREGATE_TARGET、SORT_AREA_SIZE，減少磁碟排序。
- 非同步/批次處理：若業務允許，改為非同步提交、批次彙總查詢，降低瞬間並發壓力。
驗證建議
使用 DBMS_MONITOR 或 AWR/ASH 報告，觀察並發執行時的等待事件（db file scattered read、log file sync、cursor: pin S 等），針對性調優。
結語
盲目增加執行緒並非提升查詢吞吐的銀彈。先找出瓶頸（CPU、I/O、鎖、記憶體），再從 SQL、架構、資源配置三維度優化，才能獲得穩定的效能提升。
