簡介這份PDF文檔面向使用Delphi進行企業(yè)級應(yīng)用開發(fā)的技術(shù)人員尤其是需要應(yīng)對高并發(fā)數(shù)據(jù)庫訪問場景的開發(fā)者、架構(gòu)師與DBA聚焦FireDAC連接池配置中的常見陷阱與優(yōu)化思路。文檔共54頁圍繞連接池基礎(chǔ)原理、核心參數(shù)詳解、多數(shù)據(jù)庫類型配置差異、性能優(yōu)化策略、常見問題排查及監(jiān)控自動化等模塊展開對MaxConnections、ConnectionLifeTime、RetryConnectCount等關(guān)鍵參數(shù)逐一剖析并給出連接泄漏、死鎖、超時等典型故障的診斷與修復(fù)路徑。資源包為單一PDF文件大小約4.51MB支持目錄章節(jié)跳轉(zhuǎn)與閱讀器左側(cè)大綱快速定位文字、圖表、函數(shù)與目錄顯示完整條理清晰。目前已有193人學(xué)習(xí)查閱適合希望系統(tǒng)掌握FireDAC高并發(fā)配置、避開常見坑點并提升數(shù)據(jù)庫訪問穩(wěn)定性的中高級Delphi開發(fā)者參考。1. 從一次連接池耗盡說起這份手冊到底能解決什么凌晨兩點監(jiān)控告警突然炸了——生產(chǎn)環(huán)境的訂單服務(wù)大面積超時日志里清一色[FireDAC][Phys][MySQL] Too many connections。排查到天亮才發(fā)現(xiàn)問題不在 SQL 慢查詢也不在數(shù)據(jù)庫服務(wù)器配置而是 FireDAC 連接池的MaxPoolSize設(shè)成了默認(rèn)值而業(yè)務(wù)側(cè)一個沒關(guān)好的TFDQuery把連接全占死了。這種翻車場景在 Delphi 企業(yè)級項目里幾乎每個團隊都遇到過至少一次。這份《Delphi數(shù)據(jù)庫連接池FireDAC高并發(fā)配置避坑手冊》就是沖著這類問題來的。它不是 FireDAC 的 API 字典而是一份圍繞高并發(fā)場景、把連接池參數(shù)講透、把配置陷阱標(biāo)出來的實戰(zhàn)文檔。全文 54 頁覆蓋從連接池工作原理、核心參數(shù)詳解到多數(shù)據(jù)庫配置差異、動態(tài)調(diào)優(yōu)、監(jiān)控集成和故障排查的完整鏈路。適合兩類人一是剛接手 Delphi 項目、對 FireDAC 連接池只有模糊認(rèn)知的開發(fā)者二是已經(jīng)在生產(chǎn)環(huán)境跑著高并發(fā)服務(wù)、被連接泄漏和超時問題反復(fù)折磨的架構(gòu)師。如果你正在用 Delphi 10.4 Sydney 及以上版本、FireDAC 2.0 及以上版本做多平臺數(shù)據(jù)訪問這份手冊里的參數(shù)表和配置模板可以直接抄作業(yè)。2. FireDAC 連接池的底層邏輯為什么你的配置總是不生效很多開發(fā)者配連接池的方式是“照著別人的參數(shù)抄一遍”結(jié)果發(fā)現(xiàn)同樣的MaxPoolSize50在 A 項目跑得好好的到 B 項目就頻繁超時。根本原因在于沒搞懂 FireDAC 連接池的復(fù)用機制和參數(shù)之間的聯(lián)動關(guān)系。這一章把底層邏輯拆開后面配參數(shù)時才知道每個數(shù)字在影響什么。2.1 連接池的獲取與歸還路徑FireDAC 的連接池不是獨立進程它由TFDConnection組件內(nèi)部維護。當(dāng)你調(diào)用FDConnection.Open時實際發(fā)生的是FireDAC 先檢查當(dāng)前連接定義對應(yīng)的池中是否有空閑連接有就直接復(fù)用沒有就根據(jù)MaxPoolSize判斷是否創(chuàng)建新連接。關(guān)鍵點在于——連接歸還發(fā)生在FDConnection.Close或組件釋放時而不是查詢結(jié)束后。這意味著如果你在一個方法里Open了連接、執(zhí)行完查詢卻沒有Close這個連接會一直被標(biāo)記為“使用中”池里可用連接數(shù)只減不增。常見做法是配合TFDQuery的Connection屬性自動管理但更穩(wěn)妥的方式是在try...finally里顯式關(guān)閉。下面這段代碼展示了標(biāo)準(zhǔn)的獲取與歸還路徑procedure TDataModule1.ExecuteQuerySafely; begin FDConnection1.Open; // 從池中獲取連接無空閑則按 MaxPoolSize 創(chuàng)建 try FDQuery1.Connection : FDConnection1; FDQuery1.SQL.Text : SELECT * FROM orders WHERE status :status; FDQuery1.ParamByName(status).AsString : pending; FDQuery1.Open; // 處理結(jié)果集 finally FDQuery1.Close; FDConnection1.Close; // 關(guān)鍵歸還連接到池而非物理斷開 end; end;邏輯說明FDConnection1.Open觸發(fā)池的獲取邏輯FDConnection1.Close觸發(fā)歸還邏輯。參數(shù)MaxPoolSize控制池的上限MinPoolSize控制初始化時預(yù)創(chuàng)建的連接數(shù)。如果MinPoolSize5、MaxPoolSize50啟動時池里就有 5 個連接待命并發(fā)上來后逐步擴展到 50 個超過 50 的請求會進入等待隊列等待時間由ConnectionTimeout決定。2.2 連接生命周期與空閑回收的聯(lián)動ConnectionLifeTime和ConnectionIdleTime是兩個最容易配錯的參數(shù)。前者控制連接從創(chuàng)建到被強制回收的總時長后者控制連接在池中空閑多久后被釋放。很多開發(fā)者把ConnectionLifeTime設(shè)得很大比如 86400 秒以為這樣能減少重連開銷結(jié)果遇到數(shù)據(jù)庫服務(wù)器端的wait_timeout先到期連接被服務(wù)器單方面斷開客戶端卻不知道拿到的就是一個“死連接”。正確的做法是讓ConnectionLifeTime小于數(shù)據(jù)庫服務(wù)器的超時時間。以 MySQL 為例默認(rèn)wait_timeout是 28800 秒8 小時那么ConnectionLifeTime建議設(shè)在 3600 到 7200 秒之間。ConnectionIdleTime則根據(jù)業(yè)務(wù)波峰波谷來定——如果夜間幾乎沒有請求設(shè)成 300 到 600 秒可以讓池自動收縮釋放數(shù)據(jù)庫資源。// 連接生命周期與空閑回收的推薦配置 FDConnection1.Params.Values[Pooled] : True; FDConnection1.Params.Values[MinPoolSize] : 5; FDConnection1.Params.Values[MaxPoolSize] : 50; FDConnection1.Params.Values[ConnectionLifeTime] : 3600; // 1小時強制回收 FDConnection1.Params.Values[MaxIdleTime] : 600; // 10分鐘空閑回收 FDConnection1.Params.Values[CheckConnectionSQL] : SELECT 1; // 取連接時驗證參數(shù)說明CheckConnectionSQL是容易被忽略但極其重要的參數(shù)。設(shè)置后FireDAC 在從池中取出連接時會先執(zhí)行這條 SQL 驗證連接是否仍然有效無效則丟棄并創(chuàng)建新連接。對于 MySQL 用SELECT 1Oracle 用SELECT 1 FROM DUALPostgreSQL 同樣用SELECT 1。這個驗證會帶來極小的性能開銷但能避免大量“連接已斷開”的運行時異常。2.3 連接池與其他數(shù)據(jù)訪問組件的選型差異在 Delphi 生態(tài)里BDE 已經(jīng)停止更新ADO 依賴 Windows COM 組件無法跨平臺dbExpress 雖然輕量但連接池功能薄弱。FireDAC 的優(yōu)勢在于內(nèi)置了完整的池化管理器且跨平臺支持 Windows、macOS、Linux、iOS、Android。如果你的項目需要同時部署到 Windows 服務(wù)器和 Linux 容器FireDAC 是唯一不需要改數(shù)據(jù)訪問層代碼的選擇。選型時還要注意FireDAC 的連接池是進程內(nèi)池不是跨進程的中間件池。這意味著每個應(yīng)用實例獨立維護自己的連接池部署多個實例時數(shù)據(jù)庫的總連接數(shù)等于實例數(shù)乘以單實例的MaxPoolSize。這一點在容器化部署時尤其要算清楚否則數(shù)據(jù)庫的max_connections會被瞬間打滿。3. 高并發(fā)核心參數(shù)拆解從 MaxPoolSize 到 Failover 的配置清單參數(shù)配錯一個高并發(fā)下就是連鎖反應(yīng)。這一章把 FireDAC 連接池的參數(shù)分成四組——連接管理、復(fù)用回收、錯誤重試、負(fù)載均衡——每組給出推薦值、調(diào)整邏輯和代碼模板。參數(shù)值不是固定的但調(diào)整的方向和邊界是明確的。3.1 連接管理參數(shù)MaxPoolSize 不是越大越好MaxPoolSize的設(shè)置需要同時考慮三個約束數(shù)據(jù)庫服務(wù)器的max_connections、應(yīng)用實例數(shù)量、單請求持有連接的平均時長。一個實用的估算公式是MaxPoolSize (數(shù)據(jù)庫最大連接數(shù) × 0.8) / 應(yīng)用實例數(shù)。比如 MySQL 的max_connections500部署 4 個應(yīng)用實例那么每個實例的MaxPoolSize建議不超過 100。設(shè)成 200 的后果是四個實例同時打滿數(shù)據(jù)庫直接拒絕新連接所有實例一起報錯。MinPoolSize的設(shè)置邏輯不同它影響的是冷啟動延遲。如果業(yè)務(wù)有明顯的早高峰建議把MinPoolSize設(shè)為日常平均并發(fā)連接數(shù)的 60% 到 80%這樣早高峰來臨時不需要大量創(chuàng)建新連接。但MinPoolSize設(shè)得太高低峰期會浪費數(shù)據(jù)庫資源。一個折中方案是配合動態(tài)調(diào)整策略在檢測到負(fù)載因子超過 0.8 時臨時提升MaxPoolSize。// 連接管理參數(shù)配置模板 FDConnection1.Params.Values[Pooled] : True; FDConnection1.Params.Values[MinPoolSize] : 10; // 日常平均并發(fā)的60% FDConnection1.Params.Values[MaxPoolSize] : 80; // (500*0.8)/4100留余量 FDConnection1.Params.Values[ConnectionTimeout] : 15; // 獲取連接超時秒數(shù) FDConnection1.Params.Values[LoginTimeout] : 10; // 登錄超時秒數(shù)參數(shù)說明ConnectionTimeout是從池中獲取連接的超時時間超時后拋出異常。這個值不宜設(shè)得太小否則高并發(fā)時大量請求在等待隊列中就被判超時也不宜太大否則連接泄漏時請求會長時間掛起。15 到 30 秒是常見區(qū)間。LoginTimeout是建立物理連接的超時時間與ConnectionTimeout不同它只在創(chuàng)建新連接時生效。3.2 復(fù)用回收與錯誤重試RetryConnectCount 的指數(shù)退避ReuseConnections參數(shù)控制是否啟用連接復(fù)用。在 FireDAC 中這個參數(shù)通常與Pooled配合使用。當(dāng)PooledTrue時連接復(fù)用是默認(rèn)行為但某些場景下比如需要完全隔離的會話狀態(tài)可以顯式關(guān)閉。RetryConnectCount和RetryConnectDelay是錯誤處理的關(guān)鍵參數(shù)。網(wǎng)絡(luò)抖動或數(shù)據(jù)庫短暫不可用時合理的重試策略能讓應(yīng)用自動恢復(fù)而不是直接拋異常給用戶。重試策略推薦指數(shù)退避第一次重試等待 1 秒第二次 2 秒第三次 4 秒。FireDAC 的RetryConnectDelay是固定間隔如果需要指數(shù)退避需要在OnError事件中自己實現(xiàn)。下面是一個結(jié)合了重試和異常處理的配置示例// 錯誤重試與異常處理配置 FDConnection1.Params.Values[RetryConnectCount] : 3; FDConnection1.Params.Values[RetryConnectDelay] : 1000; // 基礎(chǔ)間隔1秒 FDConnection1.Params.Values[KeepConnection] : True; // 保持連接活躍 procedure TDataModule1.FDConnection1Error(ASender: TObject; const AInitiator: IFDStanObject; var AException: Exception); begin // 記錄異常上下文便于排查 Logger.Log(Format(連接異常: %s, 錯誤碼: %d, [AException.Message, FDConnection1.RowsAffected])); // 如果是連接斷開類異常標(biāo)記需要重建連接 if Pos(lost connection, LowerCase(AException.Message)) 0 then FNeedReconnect : True; end;邏輯說明RetryConnectCount3表示連接失敗后最多重試 3 次。KeepConnectionTrue讓 FireDAC 在連接空閑時不主動斷開減少冷啟動延遲但要注意數(shù)據(jù)庫服務(wù)器的會話數(shù)限制。OnError事件是捕獲連接異常的入口在這里記錄日志比在全局異常處理中記錄更精準(zhǔn)因為能拿到 FireDAC 內(nèi)部的錯誤上下文。3.3 負(fù)載均衡與故障轉(zhuǎn)移Failover 配置的邊界Failover參數(shù)用于配置備用數(shù)據(jù)庫服務(wù)器主服務(wù)器不可用時自動切換。配置格式是分號分隔的服務(wù)器列表。但要注意FireDAC 的故障轉(zhuǎn)移是連接級別的不是事務(wù)級別的。如果主服務(wù)器在事務(wù)執(zhí)行中途宕機已經(jīng)執(zhí)行的部分不會自動回滾到備用服務(wù)器需要應(yīng)用層自己處理事務(wù)補償。LoadBalance參數(shù)啟用后FireDAC 會在多個服務(wù)器之間輪詢分配連接。這個功能適合讀多寫少的場景比如報表查詢可以分散到多個只讀副本。但寫操作必須指向主庫所以實際使用時通常需要配置兩組連接定義一組啟用LoadBalance用于讀一組不啟用用于寫。// 故障轉(zhuǎn)移與負(fù)載均衡配置 FDConnection1.Params.Values[Failover] : Serverdb-backup1;Serverdb-backup2; FDConnection1.Params.Values[LoadBalance] : True; // 動態(tài)切換連接定義讀寫分離場景 procedure TDataModule1.SwitchToReadOnly; begin FDConnection1.Connected : False; FDConnection1.ConnectionDefName : ReadOnlyPool; // 指向只讀副本組 FDConnection1.Connected : True; end;參數(shù)說明Failover的服務(wù)器列表按順序嘗試第一個可用即使用。LoadBalanceTrue時FireDAC 會在ConnectionDefs中注冊的多個服務(wù)器之間輪詢。動態(tài)切換連接定義時必須先Connected : False再改ConnectionDefName否則新定義不會生效。這個操作會觸發(fā)一次連接歸還和重新獲取在高并發(fā)下要避免頻繁切換。3.4 多數(shù)據(jù)庫配置差異對照表不同數(shù)據(jù)庫對連接池參數(shù)的支持和推薦值差異很大。下面這張表整理了 MySQL、PostgreSQL、Oracle 三種常見數(shù)據(jù)庫在 FireDAC 下的關(guān)鍵配置差異直接對照修改即可。參數(shù)MySQLPostgreSQLOracleDriverIDMySQLPGOra推薦 MaxPoolSize30默認(rèn) max_connections1515020連接資源消耗大ConnectionLifeTime3600小于 wait_timeout72003600MaxIdleTime180036001800CheckConnectionSQLSELECT 1SELECT 1SELECT 1 FROM DUAL字符集參數(shù)CharacterSetutf8mb4無需額外設(shè)置無需額外設(shè)置特殊注意連接數(shù)不超過 151支持更多并發(fā)連接每個連接消耗更多內(nèi)存提示Oracle 的FetchOptions.RowsetSize建議設(shè)為 100 到 200因為 Oracle 的網(wǎng)絡(luò)往返開銷較大批量獲取能顯著減少延遲。MySQL 和 PostgreSQL 可以設(shè)到 500 到 1000。4. 從零配置一個可用的連接池代碼模板與驗證步驟參數(shù)表看完了但真正落到代碼里順序和初始化時機同樣關(guān)鍵。這一章給出一個完整的、可以直接復(fù)制到項目里的連接池配置模板然后說明如何驗證配置是否生效。4.1 連接定義創(chuàng)建與池參數(shù)注入第一步是在TFDConnection的Params中注入池參數(shù)。注意Pooled參數(shù)必須在Open之前設(shè)置Open之后再改不會生效。連接定義可以通過FDManager.ConnectionDefs動態(tài)注冊也可以在設(shè)計器中預(yù)先配置。動態(tài)注冊的好處是可以在運行時根據(jù)環(huán)境變量切換數(shù)據(jù)庫地址。procedure TDataModule1.InitConnectionPool; begin // 動態(tài)注冊連接定義 FDManager.ConnectionDefs.AddConnectionDef( OrderDB, MySQL, Server127.0.0.1;Port3306;Databaseorder_db; User_Nameapp_user;Passwordapp_pass; ); // 注入池參數(shù) FDConnection1.ConnectionDefName : OrderDB; FDConnection1.Params.Values[Pooled] : True; FDConnection1.Params.Values[MinPoolSize] : 5; FDConnection1.Params.Values[MaxPoolSize] : 50; FDConnection1.Params.Values[ConnectionLifeTime] : 3600; FDConnection1.Params.Values[MaxIdleTime] : 600; FDConnection1.Params.Values[CheckConnectionSQL] : SELECT 1; FDConnection1.Params.Values[ConnectionTimeout] : 15; // 打開連接觸發(fā)池初始化 try FDConnection1.Open; Logger.Log(連接池初始化成功當(dāng)前池大小: IntToStr(FDConnection1.GetPooledConnectionsCount)); except on E: Exception do Logger.Log(連接池初始化失敗: E.Message); end; end;邏輯說明AddConnectionDef注冊了一個名為OrderDB的連接定義指定了 MySQL 驅(qū)動和連接字符串。FDConnection1.ConnectionDefName指向這個定義后Params中的池參數(shù)會覆蓋連接定義中的默認(rèn)值。Open調(diào)用觸發(fā)池的初始化此時MinPoolSize5個連接會被預(yù)創(chuàng)建。GetPooledConnectionsCount返回當(dāng)前池中的連接總數(shù)可以用來驗證初始化是否按預(yù)期執(zhí)行。4.2 連接池健康檢查與動態(tài)調(diào)整連接池跑起來之后需要定期做健康檢查并在負(fù)載變化時動態(tài)調(diào)整池大小。健康檢查的邏輯是遍歷池中所有連接對每個連接執(zhí)行CheckConnectionSQL失敗的連接標(biāo)記為無效并重置。動態(tài)調(diào)整則根據(jù)當(dāng)前活躍連接數(shù)與MaxPoolSize的比值來決定是否擴容或縮容。procedure TDataModule1.HealthCheckAndAdjust; var ActiveCount, MaxCount: Integer; LoadFactor: Double; begin ActiveCount : FDConnection1.GetPooledConnectionsCount; MaxCount : StrToInt(FDConnection1.Params.Values[MaxPoolSize]); LoadFactor : ActiveCount / MaxCount; // 負(fù)載超過80%擴容 if LoadFactor 0.8 then begin MaxCount : MaxCount 10; FDConnection1.Params.Values[MaxPoolSize] : IntToStr(MaxCount); Logger.Log(連接池擴容至: IntToStr(MaxCount)); end // 負(fù)載低于30%且池大小超過最小值10縮容 else if (LoadFactor 0.3) and (MaxCount 20) then begin MaxCount : MaxCount - 5; FDConnection1.Params.Values[MaxPoolSize] : IntToStr(MaxCount); Logger.Log(連接池縮容至: IntToStr(MaxCount)); end; // 驗證所有連接的健康狀態(tài) FDConnection1.ExecSQL(SELECT 1); end;參數(shù)說明GetPooledConnectionsCount返回的是池中當(dāng)前連接總數(shù)包括空閑和使用中的。負(fù)載因子用這個值除以MaxPoolSize來估算。擴容步長設(shè)為 10縮容步長設(shè)為 5避免頻繁調(diào)整導(dǎo)致抖動?？s容的下限是MinPoolSize 10防止把池縮到太小導(dǎo)致后續(xù)請求等待。健康檢查用ExecSQL(SELECT 1)是最輕量的方式但只驗證了當(dāng)前連接要驗證所有連接需要遍歷池對象。4.3 配置生效的驗證方法配完參數(shù)后怎么確認(rèn)池真的在工作三個驗證點第一啟動后立即查看GetPooledConnectionsCount應(yīng)該等于MinPoolSize第二并發(fā)執(zhí)行 100 個查詢觀察池大小是否增長到接近MaxPoolSize后不再增長第三手動關(guān)閉一個連接后池大小應(yīng)該減少再次請求時重新增長。如果池大小始終等于MinPoolSize不變化說明Pooled參數(shù)沒生效檢查是否在Open之前設(shè)置。// 驗證連接池是否生效的測試代碼 procedure TDataModule1.VerifyPoolBehavior; var I: Integer; InitialCount, AfterLoadCount: Integer; begin InitialCount : FDConnection1.GetPooledConnectionsCount; Logger.Log(初始池大小: IntToStr(InitialCount)); // 模擬并發(fā)請求 for I : 1 to 100 do begin FDConnection1.Open; try FDConnection1.ExecSQL(SELECT 1); finally FDConnection1.Close; end; end; AfterLoadCount : FDConnection1.GetPooledConnectionsCount; Logger.Log(負(fù)載后池大小: IntToStr(AfterLoadCount)); if AfterLoadCount InitialCount then Logger.Log(連接池工作正常已按需擴展) else Logger.Log(警告連接池可能未生效檢查 Pooled 參數(shù)); end;邏輯說明這段代碼先記錄初始池大小然后循環(huán) 100 次執(zhí)行“獲取連接-執(zhí)行查詢-歸還連接”的操作。如果池正常工作AfterLoadCount應(yīng)該大于InitialCount因為池會保留已創(chuàng)建的連接以備復(fù)用。如果兩者相等說明每次都在創(chuàng)建新連接并立即銷毀Pooled參數(shù)可能沒有正確設(shè)置。5. 避坑與排查連接池耗盡、泄漏、死鎖的現(xiàn)場處理參數(shù)配好了代碼也寫了但生產(chǎn)環(huán)境的問題往往不按手冊出牌。這一章整理了四個最常見的連接池故障場景每個都按“現(xiàn)象 → 原因 → 解決”的結(jié)構(gòu)給出排查路徑。這些坑我都在項目里踩過有些是配置問題有些是代碼習(xí)慣問題。5.1 連接池耗盡Too many connections 的連鎖反應(yīng)現(xiàn)象應(yīng)用日志出現(xiàn)[FireDAC][Phys][MySQL] Too many connections所有數(shù)據(jù)庫操作超時重啟應(yīng)用后短暫恢復(fù)幾分鐘后再次出現(xiàn)。原因三種可能。一是MaxPoolSize設(shè)得太大多個應(yīng)用實例同時打滿數(shù)據(jù)庫的max_connections二是連接泄漏某個代碼路徑Open后沒有Close連接被永久占用三是數(shù)據(jù)庫服務(wù)器的wait_timeout小于ConnectionLifeTime連接被服務(wù)器斷開后客戶端不知道仍然認(rèn)為連接可用。解決先查數(shù)據(jù)庫的SHOW PROCESSLIST看連接來自哪些應(yīng)用實例確認(rèn)是單實例問題還是全局問題。如果是全局問題降低每個實例的MaxPoolSize公式是(max_connections × 0.8) / 實例數(shù)。如果是單實例問題檢查代碼中所有FDConnection.Open是否都有對應(yīng)的Close推薦用try...finally包裹。如果是超時不一致問題把ConnectionLifeTime設(shè)為小于wait_timeout的值并啟用CheckConnectionSQL。5.2 連接泄漏連接數(shù)只增不減的隱形殺手現(xiàn)象應(yīng)用運行一段時間后池中連接數(shù)持續(xù)增長最終達到MaxPoolSize后新請求全部超時。重啟后恢復(fù)但再次緩慢增長。原因連接泄漏幾乎總是代碼問題。最常見的三種在except塊中忘記Close在循環(huán)中Open了連接但只在循環(huán)外Close一次使用TFDQuery時沒有設(shè)置Connection屬性導(dǎo)致每次查詢都創(chuàng)建新連接。解決用 FireDAC 的OnConnectionStateChange事件監(jiān)控連接狀態(tài)變化記錄每次Open和Close的調(diào)用棧。更直接的方法是在代碼審查中強制要求所有Open必須出現(xiàn)在try塊的第一行Close出現(xiàn)在finally塊的第一行。下面是一個防泄漏的代碼模板// 防連接泄漏的標(biāo)準(zhǔn)寫法 procedure TDataModule1.SafeQuery; begin FDConnection1.Open; try FDQuery1.Connection : FDConnection1; // 必須顯式指定 try FDQuery1.SQL.Text : SELECT COUNT(*) FROM orders; FDQuery1.Open; // 處理結(jié)果 finally FDQuery1.Close; end; finally FDConnection1.Close; // 確保任何異常下都會歸還連接 end; end;5.3 高并發(fā)死鎖連接池與事務(wù)的交叉等待現(xiàn)象高并發(fā)下部分請求卡死數(shù)據(jù)庫端出現(xiàn)死鎖告警應(yīng)用日志顯示事務(wù)等待超時。原因連接池中的連接被事務(wù)長時間持有其他請求等待連接釋放而持有連接的請求又在等待數(shù)據(jù)庫鎖釋放形成交叉等待。典型場景是事務(wù) A 持有連接 1 并等待行鎖事務(wù) B 持有行鎖并等待連接 2而連接 2 被事務(wù) A 占用。解決縮短事務(wù)持有連接的時間。具體做法事務(wù)中只包含必要的 SQL 操作不要在事務(wù)中做網(wǎng)絡(luò)調(diào)用或文件 IO設(shè)置CommandTimeout限制單條 SQL 的執(zhí)行時間對于批量操作分批提交而不是一個大事務(wù)包到底。FireDAC 的Transaction對象支持StartTransaction和Commit確保每個事務(wù)都有明確的邊界。5.4 連接超時ConnectionTimeout 與網(wǎng)絡(luò)抖動的博弈現(xiàn)象偶發(fā)性連接超時日志顯示ConnectionTimeout expired但數(shù)據(jù)庫服務(wù)器負(fù)載正常。原因ConnectionTimeout設(shè)得太小高并發(fā)時請求在池的等待隊列中排隊還沒輪到就被判超時?；蛘呔W(wǎng)絡(luò)存在間歇性抖動物理連接建立時間超過LoginTimeout。解決把ConnectionTimeout從默認(rèn)的 10 秒調(diào)整到 15 到 30 秒給等待隊列留出緩沖。同時啟用RetryConnectCount讓超時后的請求自動重試。如果是網(wǎng)絡(luò)抖動問題檢查應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器之間的網(wǎng)絡(luò)質(zhì)量必要時增加LoginTimeout到 15 秒。注意ConnectionTimeout和LoginTimeout是兩個不同的參數(shù)前者管獲取連接后者管建立物理連接。注意排查連接超時問題時先看數(shù)據(jù)庫服務(wù)器的Threads_connected和Threads_running如果這兩個值遠(yuǎn)低于max_connections說明瓶頸在應(yīng)用側(cè)的池配置而不是數(shù)據(jù)庫。6. 進階用事件監(jiān)控和日志把連接池變成白盒連接池配好之后最怕的是出問題時看不到內(nèi)部狀態(tài)。FireDAC 提供了一組事件接口可以在連接獲取、歸還、創(chuàng)建、銷毀時觸發(fā)回調(diào)把這些事件接到日志系統(tǒng)里連接池就從黑匣子變成了白盒。這一章給出一個基于事件的監(jiān)控實現(xiàn)以及如何把監(jiān)控數(shù)據(jù)輸出到日志和告警系統(tǒng)。6.1 用 OnConnectionStateChange 追蹤連接流轉(zhuǎn)TFDConnection的OnConnectionStateChange事件在連接狀態(tài)變化時觸發(fā)可以拿到當(dāng)前是獲取還是歸還、連接是否有效。把這個事件接到日志里每次連接流轉(zhuǎn)都有記錄排查泄漏時直接看日志就能定位到哪次Open沒有對應(yīng)的Close。procedure TDataModule1.FDConnection1StateChange(Sender: TObject); var StateStr: string; begin case FDConnection1.State of csInactive: StateStr : 未連接; csOpening: StateStr : 正在打開; csOpen: StateStr : 已連接; csClosing: StateStr : 正在關(guān)閉; csClosed: StateStr : 已關(guān)閉; end; Logger.Log(Format([連接池] 狀態(tài)變化: %s, 池大小: %d, 時間: %s, [StateStr, FDConnection1.GetPooledConnectionsCount, FormatDateTime(yyyy-mm-dd hh:nn:ss.zzz, Now)])); end;邏輯說明OnConnectionStateChange在Open和Close時都會觸發(fā)通過State屬性區(qū)分當(dāng)前狀態(tài)。日志中記錄池大小和時間戳如果發(fā)現(xiàn)池大小持續(xù)增長而狀態(tài)在csOpen和csClosed之間頻繁切換說明連接創(chuàng)建和銷毀的頻率過高可能需要調(diào)大MinPoolSize。如果池大小只增不減說明存在泄漏。6.2 自定義監(jiān)控指標(biāo)與告警閾值除了日志還可以把連接池的關(guān)鍵指標(biāo)暴露給外部監(jiān)控系統(tǒng)。FireDAC 沒有內(nèi)置的 Prometheus 接口但可以通過定時采樣把指標(biāo)寫入日志文件再由日志采集器轉(zhuǎn)發(fā)。關(guān)鍵指標(biāo)包括當(dāng)前池大小、活躍連接數(shù)、等待隊列長度、連接創(chuàng)建速率、連接銷毀速率。指標(biāo)采集方式告警閾值含義池大小GetPooledConnectionsCount持續(xù)等于 MaxPoolSize 超過 5 分鐘池已打滿請求在排隊活躍連接數(shù)池大小 - 空閑連接數(shù)超過 MaxPoolSize 的 90%接近容量上限連接創(chuàng)建速率單位時間內(nèi) Open 次數(shù)超過 10 次/秒池太小或泄漏連接銷毀速率單位時間內(nèi) Close 次數(shù)與創(chuàng)建速率嚴(yán)重不匹配可能存在泄漏等待超時次數(shù)ConnectionTimeout 異常計數(shù)超過 5 次/分鐘池容量不足或泄漏采集這些指標(biāo)的方式是在OnConnectionStateChange中累加計數(shù)器然后每分鐘輸出一次匯總?cè)罩?。告警閾值可以根?jù)實際業(yè)務(wù)調(diào)整但“池大小持續(xù)等于 MaxPoolSize”是最關(guān)鍵的信號出現(xiàn)這個信號說明池已經(jīng)不夠用了。6.3 一個具體的調(diào)優(yōu)習(xí)慣從那以后我每次上線新的 Delphi 服務(wù)都會強制走一遍連接池壓測用 200 個并發(fā)線程跑 10 分鐘觀察池大小的變化曲線。如果曲線在 5 分鐘內(nèi)就沖到MaxPoolSize并保持水平說明池太小或者有泄漏如果曲線在MinPoolSize和MaxPoolSize之間平穩(wěn)波動說明配置合理。壓測時還會故意殺掉一個數(shù)據(jù)庫連接驗證CheckConnectionSQL是否能自動剔除死連接。這個習(xí)慣幫我提前發(fā)現(xiàn)了至少三次潛在的連接泄漏比等到生產(chǎn)環(huán)境告警再排查省了太多時間。希望幫到你。本文還有配套的精品資源點擊獲取