mysql長連接
① php mysql 長連接怎麼用
直接和連接資料庫方法是一樣的，沒有區別。
還有什麼不懂可以追問。
② C#如何創建mysql 短連接，長連接
stringDataSources.AllConstant.mysqlconnstr="DataBase=erp_105;Server=127.0.0.1;UserId=dev;Password=xdev2;port=3306;charset=utf8"
using(MySqlConnectionconn=newMySqlConnection(DataSources.AllConstant.mysqlconnstr)){
conn.Open();
}
③ php mysql的長連接和短連接
可以這樣封裝個函數
function login（$a=false）
{
if(!$a)
{
$db=mysql_pconnect('localhost','user','pass');
}else
{
$db=mysql_connect('localhost','user','pass');
}
}
可以調用login（）默認參數為false 修改傳遞的回參數就行了答
④ php mysql一直連接跟每次連接都斷開有區別嗎
區別很大，一直連接的話，這就涉及到資料庫的並發連接數，如果並發連接數是100，則表示同時可以有100個人連接資料庫，第101個人訪問時會被拒絕。
所以通常的做法都是用完資料庫就斷開，釋放資源。
⑤ MYSQL長短連接什麼情況下使用
短鏈接抄的缺點：創建襲一個連接，程序執行完畢後，就會自動斷掉與mysqlserver的鏈接。於是多少次php執行，就會多少次這樣的創建和釋放過程。頻繁地創建和釋放連接，比較耗費cpu資源。
長連接就可以避免每次請求都創建連接的開銷，節省了時間和IO消耗。
長連接是提高了性能。不過還有一些細節的問題需要解決，即mysql發現一個鏈接長時間沒有執行查詢請求，就會自動斷掉這個連接。
⑥ mysql長連接和短連接通過什麼確定
長連接就是一直連接著mysql，即使空閑時候也鏈接著
短連接就是連接完關閉鏈接，需要的時候重新鏈接
⑦ php mysql一直連接跟每次連接都斷開有區別嗎
二者區別：
一直連接屬於長連接，網站加入並發請求數會很多，如果同時有很多人來訪問的網站，並且每個訪問者都需要查詢一次mysql資料庫的話，會很快把系統資源消耗完畢，但是，頻繁查詢時，長連接節省時間。
每次連接都屬於短鏈接，每次查詢完就馬上關閉，不容易消耗過多的系統資源，但是，頻繁查詢時，相對長連接比較消耗時間。
⑧ thinkphp 中MySQL默認是長連接嗎
會不會是正式資料庫數據量大的原因？你可以試著加一些索引
不會是長連接的，這是HTTP的特性 在執行sql的時候才會進行連接
⑨ mysql什麼場景下才需要用長連接
長連接就可以避免每次請求都創建連接的開銷，節省了時間和IO消耗。
長連接是提高了性能。不過還有一些細節的問題需要解決，即mysql發現一個鏈接長時間沒有執行查詢請求，就會自動斷掉這個連接。
⑩ net mysql.data 默認是長連接嗎
有台伺服器，訪問量挺大，每天近250w動態pv，資料庫查詢平均每秒近600次 另一台伺服器，跑的程序跟這台一樣，不過只有每天約40w動態pv 前段時間連續卡死過幾次，當時的狀態是 伺服器沒崩潰，資料庫可正常登陸。只是所有的查詢都卡在「sending data」狀態，長時間無法執行完，這些簡單的sql語句，有時候集中在A表上，有時候集中在B表上，同時還有一些卡死在locked狀態或update狀態 看mysql的說明，sending data狀態表示兩種情況，一種是mysql已經查詢了數據，正在發給客戶端；另一種情況是，mysql已經知道某些數據需要去什麼地方讀取，正在從數據文件中讀取 mysql官方說，這不是mysql的bug，但是官方也沒說怎麼處理......那麼，看情況，就應該是配置方面的問題了。 首先從sql優化的角度來查了查，那些卡死的sql語句，都是簡單查詢，消耗非常低，索引做的非常好，所以覺得應該不是sql語句的問題。而且慢查詢日誌里也沒有出現慢查詢。 把表都做了優化，就是optimize table ，過幾天發現，還是會出現卡死的情況..... 後來考慮增加並發性能，增加了key_buffer thread_cache 等一系列的內存配置，發現沒什麼作用。情況依舊 再後來，把query_cache減小到默認值 16M，把一些不怎麼變動的數據，做了靜態化。驚奇的發現，12天過去了，沒再出過問題...... 後來想想，修改query_cache可能對這個問題有些幫助，畢竟數據更新比較頻繁，query_cache的更新也很頻繁。不過看mysql的狀態，query_cache的命中率還是相當高的，差不多75％。 覺得問題可能出在程序上，只是沒查出來。後來靜態化的那些內容，是一些產品的說明文字，一般一個產品的說明也就三五十個漢字。 這里出問題的嫌疑比較大，一個頁面有七八個產品，加起來可能三五百個漢字，雖然不多，不過查詢很頻繁，從這個表上查詢的數據量應該是很可觀的，mysql會頻繁的從這個表拿數據。不過，不過有時候卡死的語句並不是在查詢這個表...... 手頭沒有好使的工具，郁悶。反正問題貌似好了，先放下備案吧，等以後水平高些，再來查。 MySQL很容易進程滿而死的一個重要原因 建站不容易已經遠遠超過了我的設想和預期,除了經濟上還有技術上的,有些問題不是一般技術人員能解決。不過在這段時間里讓我也學會了如何思考問題和解決問題，特別是連續解決了幾個問題，可以說真不是開發人員或者別的技術人員能解決的，對此自信心也越來越足了! 談到這，必須說下我們的站布衣生活網，基本配置，LINUX 9.0系統,JBOSS42 WEB服務，MYSQL，從五一到現在，運行有段時間了，目前的訪問量是4000IP左右。 記得以前發生過一個問題也是檢查了好久都沒解決的，故障一發生CPU就跑到100%左右，系統沒響應，MYSQL、JBOSS進程死。當初是通過對一些大數據表建立索引解決的!這次問題現象和這個有點象，死的時候幾乎服務沒有響應，通過查看後台MYSQL進程，居然已經超過我設置的1000個限制，第1天我把配置改成3000，想想是否跟這個有關，最近的訪問量增大了。說實話，我還是不相信並發1000個連接，但事實擺在面前，現在就是1000個進程堵在這!第2天發現3000也不行了，在進程列表中看到基本上很容易就進程滿，而且每個進程都在sending data 狀態，查找了2天還是無法解決問題，不論是重新配置啟動參數還是檢查外來攻擊都無法解決，按照一些人的說法，把臨時緩沖表增大到512M也是沒有任何幫助。象這種的每增加個連接都幾乎會卡死，而且是sending data 狀態!是數據無法發出還是查詢不能完成呢? 帶著這個問題，跟開發的溝通，是否存在數據死鎖或者沒有提交的問題，造成的查詢鎖死!而且有時候是正常，但大部分是不正常的死鎖!查了半天，報告說，程序沒發現問題，因為根據命令已經能定位到程序的准確代碼上了!那麼是什麼問題呢? 想起以前MS SQLSERVER2000下曾經發生過的資料庫損壞的問題，也嘗試了修復。根據堵塞命令集中在幾個重要的表上，其一是餐館信息表(4萬條記錄)，用修復命令都無法修復!發現設置的類型是inoubox ,把類型改成MYISAM 後再修復，修復也沒報告什麼錯誤，但重新啟動系統後一切問題就解決了!