永久的資料庫連線是指在腳本結束運行時不關閉的連線。當收到一個永久連線的請求時。 PHP 將檢查是否已經存在一個（前面已經開啟的）相同的永久連線。如果存在，將直接使用這個連接；如果不存在，則建立一個新的連接。所謂「相同」的連線是指用相同的使用者名稱和密碼到相同主機的連線。
對 web 伺服器的工作和分佈負載沒有完全理解的讀者可能會錯誤地理解永久連接的作用。特別的，永久連線不會在相同的連線上提供建立「使用者會話」的能力，也不提供有效建立事務的能力。實際上，從嚴格意義上來講，永久連接不會提供任何非永久連接無法提供的特殊功能。
為什麼？
這和 web 伺服器的工作方式有關。 web 伺服器可以用三種方法來利用 PHP 產生 web 頁面。
第一種方法是將 PHP 用作「外殼」。以這種方法運行，PHP 會為向 web 伺服器提出的每個 PHP 頁面請求產生並結束一個 PHP 解釋器執行緒。由於該執行緒會隨每個請求的結束而結束，因此任何在這個執行緒中利用的任何資源（例如指向 SQL 資料庫伺服器的連線）都會隨執行緒的結束而關閉。在這種情況下，使用永久連接不會獲得任何地改變——因為它們根本不是永久的。
第二，也是最常用的方法，就是把 PHP 用作多進程 web 伺服器的一個模組，這種方法目前只適用於 Apache。對於一個多進程的伺服器，其典型特徵是有一個父進程和一組子進程協調運行，其中實際產生 web 頁面的是子進程。每當客戶端向父進程提出請求時，該請求會傳遞給尚未被其它的客戶端請求佔用的子進程。這也就是說當相同的客戶端第二次向服務端提出請求時，它將有可能被一個不同的子程序來處理。在開啟了一個永久連線後，所有請求 SQL 服務的後繼頁面都能夠重新使用這個已經建立的 SQL Server 連線。
最後一種方法是將 PHP 用作多執行緒 web 伺服器的一個外掛程式。目前PHP 4 已經支援ISAPI、WSAPI 和NSAPI（在Windows 環境下），這些使得PHP 可以被用作諸如Netscape FastTrack (iPlanet)、Microsoft's Internet Information Server (IIS) 和O'Reilly's WebSite Pro 等多執行緒web 伺服器的插件。永久連結的行為和前面所描述的多過程模型在本質上是相同的。注意 PHP 3 不支援 SAPI。
如果永久連接並沒有任何附加的功能，那麼使用它有什麼好處？
答案非常簡單——效率。當客戶端對 SQL 伺服器的連線請求非常頻繁時，永久連線將會更有效率。連線請求頻繁的標準取決於許多因素。例如，資料庫的種類，資料庫服務和 web 服務是否在同一台伺服器上，SQL 伺服器如何載入負載等。但我們至少知道，當連線請求很頻繁時，永久連線將顯著的提高效率。它使得每個子進程在其生命週期中只做一次連接操作，而非每次在處理一個頁面時都要向 SQL 伺服器提出連接請求。這也就是說，每個子進程將對伺服器建立各自獨立的永久連線。例如，如果有 20 個不同的子進程運行某腳本建立了永久的 SQL 伺服器永久連接，那麼實際上向該 SQL 伺服器建立了 20 個不同的永久連接，每個進程佔有一個。
注意，如果永久連接的子進程數目超過了設定的資料庫連線數限制，系統將會產生一些缺陷。如果資料庫的同時連接數限制為 16，而在繁忙會話的情況下，有 17 個線程試圖連接，那麼有一個線程將無法連接。如果這個時候，在腳本中出現了使得連線無法關閉的錯誤（例如無限循環），則該資料庫的 16 個連線將迅速受到影響。請查閱使用資料庫的文檔，以取得如何處理已放棄的及閒置的連線的方法。
在使用永久連接時還有一些特別的問題需要注意。例如在永久連線中使用資料表鎖時，如果腳本不管什麼原因無法釋放該資料表鎖，其隨後使用相同連線的腳本將會被永久的阻塞，使得需要重新啟動 httpd 服務或資料庫服務。另外，在使用事務處理時，如果腳本在事務阻塞產生前結束，則該阻塞也會影響到使用相同連線的下一個腳本。不管在什麼情況下，都可以透過使用 register_shutdown_function() 函數來註冊一個簡單的清理函數來開啟資料表鎖，或是回滾事務。或者更好的處理方法，是不在使用資料表鎖或事務處理的腳本中使用永久連接，這可以從根本上解決這個問題（當然還可以在其它地方使用永久連接）。
以下是一點重要的總結。永久連接是為通常連接建立一對一的分佈而設計的。這意味著必須能夠保證在將永久連線替換為非永久連線時，腳本的行為不會改變。使用永久連接將（非常）有可能改變腳本的效率，但不改變其行為！
