免責聲明，我不負責管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 真的調得很好