正常情況下，對於資料庫的open然後close,是沒有任何問題的
但是當大家覺得這種open或者close多了的時候會影響資料庫的效能，嗯，經過測試確實很影響效能。可能相差很多倍；
於是產生了連線池和某些其他持久化連線方案。
但是有些東西非常重要，就是連線次也好，其他持久化也好，對於資料庫來說都不是即時關閉，有的時候會導致在資料庫層面開啟的socket一直存在，存在達到8個小時；
很多資料庫連線池的設計可能對於資料庫的通訊並不熟悉，或者很多人在使用方案的不完備導致資料庫的連線關閉沒有
最後達到了max_connection.然後新的資料庫請求進不來，從而整個系統癱瘓。這種癱瘓其實並不是大流量導致的，而是資料庫連線釋放的問題；
所以有的時候對於很多系統來說使用的技術越落後反而越穩健。
wait_timeout
interactive_timeout
上面這兩個引數都是8個小時。
如果你使用php的mysqli的持久化方案，某些情況下php異常後，在max_connection以上的使用者就進不來了。必須等8個小時自然釋放。
由於mysqli在持久化的時候對於持久化的標識有ip做為依據，所以你在同乙個ip的測試下始終都是乙個mysql的連線，但是ip一多，你就懂了。
這種問題的根源其實有2：
1，對於連線層的方案不熟悉使用了方案；
2，對於資料庫的連線機制不熟悉寫了連線層。
那種只open，不close的情況都不說了。
補充一下：
連線池裡面的連線數一定要小於資料庫允許的max_connection，留出一下活路；或者某些關鍵地方的資料庫操作不使用連線池？
關於資料庫連線的一些問題
問題2 the server time zone value is unrecognized or represents more than one time zone 問題分析 mysql在識別時區時出現錯誤，也就是說訪問的url中沒有指定時區 connectionproperties useun...
關於資料庫連線池的一些思考
我們都知道資料庫連線池的作用，初始時它首先向資料庫申請多個連線，然後由它負責分配,管理和釋放資料庫連線,它允許應用程式重複使用乙個現有的資料庫連線,而不是重新建立乙個。雖然知道了連線池的作用，但是更重要的一點是我們該如何配置，使得連線池的效能最優。而這裡最為顯著的問題就是如何設定連線池的連線數。假設...
定義資料庫連線的一些常量
定義資料庫連線的一些常量 const adopenforwardonly 0 游標只向前瀏覽記錄，不支援分頁 recordset bookmark const adopenkeyset 1 鍵集游標，其他使用者對記錄說做的修改將反映到記錄集中，但其他使用者增加或刪除記錄不會反映到記錄集中。支援分頁 ...