正常情況下，對於數據庫的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，留出一下活路；或者某些關鍵地方的數據庫操作不使用連接池？