|
|
但是正常來說，MySQL默認的100個連接數(shù)是足夠的。我們需要從程序上去考慮。MySQL的默認最大連接數(shù)為100（N），實際給普通用戶使用只有N-1個，保留一個連接是留給超級管理員使用的，防止連接占滿了不會把管理員也踢出來。很多網(wǎng)站在運行的時候都會出現(xiàn)連接數(shù)受限現(xiàn)象，我認為十之八九并非是網(wǎng)站的真實訪問量太大導(dǎo)致連接數(shù)超標，更多是因為我們在設(shè)計網(wǎng)站程序的時候采用了不合理的設(shè)計架構(gòu)或數(shù)據(jù)結(jié)構(gòu)引起的。非正常連接超限可能原因如下（天緣即時歸納未必完整或無錯訛僅供參考）：
類似人數(shù)、在線時間、瀏覽數(shù)等統(tǒng)計功能與主程序數(shù)據(jù)庫同屬一個數(shù)據(jù)空間時就很容易出現(xiàn)。
復(fù)雜的動態(tài)頁尤其是用戶每次瀏覽都涉及到多數(shù)據(jù)庫或多表操作時候也很容易出現(xiàn)。
還有就是程序設(shè)計的不合理（比如復(fù)雜運算、等待等操作放置在數(shù)據(jù)庫交互行為中間進行），或者程序存在釋放BUG。
計算機硬件配置太低卻安裝太高版、太高配置的MySQL。
未采用緩存技術(shù)。
數(shù)據(jù)庫未經(jīng)過優(yōu)化或表格設(shè)計及其復(fù)雜。
等等一些原因，都會延長數(shù)據(jù)庫的數(shù)據(jù)交互時間或增加交互次數(shù)。所以，如果大家遇到這類問題，首先要考慮程序是否存在BUG導(dǎo)致連接釋放失敗，再次就是考慮優(yōu)化軟硬件。當(dāng)然修改MySQL連接數(shù)也是軟件優(yōu)化的操作方法之一，希望大家都能夠本著學(xué)習(xí)的態(tài)度通過研究一下自身的原因從而解決這一問題。如果實在是找不到原因，那就只好先修改連接數(shù)，暫緩定位真實原因了。
關(guān)于php的數(shù)據(jù)庫持久連接 mysql_pconnect
php程序員應(yīng)該都知道連接MySQL數(shù)據(jù)庫可以使用mysql_pconnect（永久連接）函數(shù)，使用數(shù)據(jù)庫永久連接可以提高效率，但是實際應(yīng)用中數(shù)據(jù)庫永久連接往往會導(dǎo)致出現(xiàn)一些問題，通常的表現(xiàn)就是在大訪問量的網(wǎng)站上時常發(fā)生斷斷續(xù)續(xù)的無法連接數(shù)據(jù)庫的情況，出現(xiàn)類似＂Too many connections in ...＂的錯誤提示信息，重新啟動服務(wù)器又正常了，但過不了一會兒又出現(xiàn)同樣的故障。對于這些問題的成因，恐怕就不是每個人都能說清楚的了，雖然php文檔里有一些相關(guān)資料，但是解釋的并不淺顯易懂，這里我厚著臉皮試圖做一個簡單的討論，所述觀點不見得全都正確，歡迎大家反饋意見。
首先看看數(shù)據(jù)庫永久連接的定義：永久的數(shù)據(jù)庫連接是指在腳本結(jié)束運行時不關(guān)閉的連接。當(dāng)收到一個永久連接的請求時。php 將檢查是否已經(jīng)存在一個（前面已經(jīng)開啟的）相同的永久連接。如果存在，將直接使用這個連接；如果不存在，則建立一個新的連接。所謂"相同"的連接是指用相同的用戶名和密碼到相同主機的連接。
php使用永久連接方式操作MySQL是有前提的：就是php必須安裝為多線程或多進程Web服務(wù)器的插件或模塊。最常見的形式是把php用作多進程Apache服務(wù)器的一個模塊。對于一個多進程的服務(wù)器，其典型特征是有一個父進程和一組子進程協(xié)調(diào)運行，其中實際生成Web頁面的是子進程。每當(dāng)客戶端向父進程提出請求時，該請求會被傳遞給還沒有被其它的客戶端請求占用的子進程。這也就是說當(dāng)相同的客戶端第二次向服務(wù)端提出請求時，它將有可能被一個不同的子進程來處理。在開啟了一個永久連接后，所有不同子進程請求SQL服務(wù)的后繼頁面都能夠重新使用這個已經(jīng)建立的 SQL服務(wù)器連接。它使得每個子進程在其生命周期中只做一次連接操作，而非每次在處理一個頁面時都要向 SQL 服務(wù)器提出連接請求。每個子進程將對服務(wù)器建立各自獨立的永久連接。php本身并沒有數(shù)據(jù)庫連接池的概念，但是Apache有進程池的概念, 一個Apache子進程結(jié)束后會被放回進程池, 這也就使得用mysql_pconnect打開的的那個mysql連接資源可以不被釋放，而是依附在相應(yīng)的Apache子進程上保存到了進程池中。于是在下一個連接請求時它就可以被復(fù)用。一切看起來似乎都很正常，但是在Apache并發(fā)訪問量大的時候，如果使用mysql_pconnect，會由于之前的Apache子進程占用的MySQL連接沒有close, 很快使MySQL達到最大連接數(shù)，使得之后的請求可能得不到響應(yīng)。
上面的部分文字是摘抄自php文檔，看起來可能還是有些文縐縐的不好理解，那么我就用大白話再舉一個例子來說明問題：
假設(shè)Apache配置最大連接數(shù)為1000，MySQL配置最大連接數(shù)為100，當(dāng)Apache服務(wù)器接到200個并發(fā)訪問的時候，其中100個涉及到數(shù)據(jù)庫訪問，剩下的100個不涉及數(shù)據(jù)庫訪問，因為這個時候還不存在可用的數(shù)據(jù)庫連接，所以這里面涉及到數(shù)據(jù)庫訪問的100個并發(fā)會同時產(chǎn)生100個數(shù)據(jù)庫永久連接，達到了數(shù)據(jù)庫最大連接數(shù)，當(dāng)這些操作沒有結(jié)束的時候，任何其他的連接都無法再獲得數(shù)據(jù)庫連接，當(dāng)這些操作結(jié)束了，相應(yīng)的連接會被放入進程池，此時Apache的進程池里就有了200個空閑的子進程，其中100個是帶有數(shù)據(jù)庫連接的，由于Apache會為訪問請求隨機的挑選空閑子進程，所以你得到的子進程很可能是不包含數(shù)據(jù)庫連接的那100個中的一個，而數(shù)據(jù)庫連接已經(jīng)達到了最大值，你也不可能成功的建立新的數(shù)據(jù)庫連接，唉，你便只好不停的刷新頁面，哪個時候運氣好，碰巧分配到了帶有數(shù)據(jù)庫連接的子進程，才能正常瀏覽頁面。如果是大訪問量的網(wǎng)站來說，任何時候都可能存在大量的并發(fā)，所以瀏覽者可能就會不停的發(fā)現(xiàn)無法連接數(shù)據(jù)庫的現(xiàn)象了。
或許你會說，我們把Apache和MySQL的最大連接數(shù)調(diào)成一樣大不就可以了么？是的，合理的調(diào)整這個最大連接數(shù)某種程度上會避免這個問題的發(fā)生，但是Apache和MySQL的負載能力是不同的，如果按照Apache的負載能力來設(shè)置，對于MySQL來說，這個最大連接數(shù)就偏大，會產(chǎn)生大量的MySQL數(shù)據(jù)庫永久連接，打個比方，就好像和平時代還要養(yǎng)活一個幾百萬的軍隊一樣，其開銷得不償失；而如果按照Mysql的負載能力設(shè)置，對于Apache來說，這個最大連接數(shù)就偏小，有點殺雞牛刀的感覺，無法發(fā)揮Apache的最大效率。
所以按照php手冊上的介紹，只適合在并發(fā)訪問不大的網(wǎng)站上使用數(shù)據(jù)庫永久連接，但對于一個并發(fā)訪問不大的網(wǎng)站來說，使用數(shù)據(jù)庫永久連接帶來的效率提高似乎沒有太大的意義，從這個角度上來看，我覺得php中的數(shù)據(jù)庫永久連接基本上是一個雞肋的角色，如果你一定要使用數(shù)據(jù)庫連接池的概念，可以嘗試一下sqlrelay或者Apache本身提供的mod_dbd，說不定會有驚喜。
關(guān)于mysql_free_result和mysql_close
之前用mysql的時候一直是在用短鏈接，調(diào)用mysql_store_result獲取一次數(shù)據(jù)之后就直接調(diào)用：
復(fù)制代碼 代碼如下:
mysql_free_result(m_result);
mysql_close(m_Database);
但是有兩個問題：
當(dāng)使用長連接時（即connect之后一直不close），如果最后會調(diào)用mysql_close，需不需要每次都調(diào)用mysql_free_result呢?
當(dāng)mysql_close調(diào)用之后，m_result的數(shù)據(jù)是否還可以用。
先說一下結(jié)論：
必須每次調(diào)用。因為經(jīng)過測試，每次mysql_store_result的指針都是不同的，可見并不是共享了同一塊buf。
還是可以使用。經(jīng)過valgrind掃描，只調(diào)用mysql_close的掃描結(jié)果是：
復(fù)制代碼 代碼如下:
==9397== 16,468 (88 direct, 16,380 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 5
==9397== at 0x40219B3: malloc (vg_replace_malloc.c:195)
==9397== by 0x8053EA2: my_malloc (in /data/home/dantezhu/appbase/application/platform/openqqcom/share/db_openright/test/test)
==9397== by 0x806D314: mysql_store_result (in /data/home/dantezhu/appbase/application/platform/openqqcom/share/db_openright/test/test)
==9397== by 0x804BB04: CMySQLCppClient::Result(st_mysql_res*&) (mysql_cpp_client.cpp:127)
==9397== by 0x804AB58: CDBOpenRight::GetUinsByApp(unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&) (db_openright.cpp:58)
==9397== by 0x8049F10: main (test.cpp:27)
以后再慢慢研究。。
php技術(shù)：MySQL連接數(shù)超過限制的解決方法，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
