免責聲明，我不負責管DB，我最討厭管機器了 以下建議請跟你們家 DBA 討論，我們家的經驗不一定適合你們家 ※ 引述《liisi (小心一點)》之銘言： : 今天中午和晚上 又發生一次 : process 每個都在sending data 我用「mysql index sending data」找到一些東西，不知道能不能幫到你 https://www.google.com.tw/search?q=mysql+index+sending+data https://read01.com/6nEeN.html 我沒有看得很懂，但是大概是「欄位們之中有肥肥的欄位把什麼東西弄爆了」 不確定這跟你碰到的狀況是否相同 如果是這個問題，那應急解法也許會是「select 時若可以不要連胖欄位一起撈」 另外是這問題看起來是東西沒載到 RAM 裡面於是卡 IO 換句話說有個超級不要臉的解法是改用 SSD 我自己是看過背景在跑的三四千秒 query（是的我知道這很 suck）靠SSD變成五分鐘 裝 SSD 跟吸毒一樣不健康而且會上癮。這招雖然可恥但有用。 不過我對 SSD 實際的 fail rate 沒有概念。使用這招之前要確保你們家資料強固性夠 另外我對你們家的狀況感到有點趣味 : 我們是用 mysql 5.3 我不認識這版本，只跟 5.5+ 打過交道，推測這大概快十年前的東西了 可能的話規劃一下升級？ 話說回來，你們要升這麼大一級大概也會很痛，可能不是有心就做得到... : 商品不是10幾萬筆 是幾十萬筆 : 且每一天 都會增加幾百筆以上 : 商品的結構 分成2個table (之前的人設計的) 上面的連結有提到分 table 的可能理由。兩個 table 的大小看來也符合。 : 1個 good_info1 , 1個 good_info2 : info1 有幾百M , info2卻有5G 是1對1的關係 info1有幾筆 info2就有幾筆 假設是 50 萬筆，500M, 5G 那就是一個商品平均 11K，有點胖胖的。 我會猜是大家都有把商品描述寫好寫滿，所以文字資料量大。 如果你們用 InnoDB 但沒開壓縮，建議開一下，可以省一些硬碟空間跟IO時間。 如果你們用 InnoDB 且已經開了壓縮，那我會懷疑裡面是不是有圖檔之類的 blob 個人是不推薦把二進位資料放在這種公開接客的 DB 裡面 以圖檔來說會建議另外弄靜態檔案服務，世界會美好很多 如果你們用 MyISAM，那是另外一個境界的問題... 如果我都猜錯，那....家家有本難念的經... ================= 另外關於 join，我自己的經驗是「只要有好好吃到 index 那 overhead 可忽略」 跟其他地方看到「Join有一定代價」的經驗有差距 這部分我有想到幾個可能原因，我不知道正解為何： - 我們家全部用 InnoDB 所以不會像 MyISAM 在那邊一直被 table lock 卡全場 - 我們家 DB 機規格好（用錢能解決的都是小問題） - 我們家 DBA 真的調得很好 -- 莉娜用魔法爆破進入屋內。 劫犯從另一個房間裡出現，大叫道︰「妳是誰！」 莉娜︰「我是個可疑的女人！」 劫犯無言以對。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.27.54.84 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/PHP/M.1487432487.A.590.html ※ 編輯: GALINE (114.27.54.84), 02/19/2017 00:01:00 ※ 編輯: GALINE (114.27.54.84), 02/19/2017 00:31:34