mysql 卡逝世 年夜部門線程長時光處於sending data的狀況。本站提示廣大學習愛好者：（mysql 卡逝世 年夜部門線程長時光處於sending data的狀況）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql 卡逝世 年夜部門線程長時光處於sending 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很輕易過程滿而逝世的一個主要緣由
建站不輕易曾經遠遠跨越了我的假想和預期,除經濟上還有技巧上的,有些成績不是普通技巧人員能處理。不外在這段時光裡讓我也學會了若何思慮成績息爭決成績，特殊是持續處理了幾個成績，可以說真不是開辟人員或許其余技巧人員能處理的，對此自負心也愈來愈足了!
談到這，必需說下我們的站平民生涯網www.yes81.net，根本設置裝備擺設，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 後再修復，修復也沒申報甚麼毛病，但從新啟動體系後一切成績就處理了!
