Re: [請益] 在資料表上加上索引，卻讓mysql過載

[GALINE (天真可愛CQD)]

免責聲明，我不負責管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://www.ptt.cc/bbs/PHP/M.1487432487.A.590.html
※ 編輯: GALINE (114.27.54.84), 02/19/2017 00:01:00
→ iFEELing: join一定有代價 只是調得好的話代價比較低
→ iFEELing: PLAN歪掉的話就可以看見代價大爆發.....
→ GALINE: 我會認定plan歪掉=沒吃到index，而這不算是join的錯..吧？
→ GALINE: 有碰過統計table清空後plan出蠢東西然後效能炸掉，後來用
→ GALINE: sub query來逼mysql吃到要的index。
→ GALINE: 不過我也真不知道我們家DBA背地裡做了多少努力...(汗
※ 編輯: GALINE (114.27.54.84), 02/19/2017 00:31:34
→ iFEELing: plan歪掉也有可能merge/sort大爆炸...先後順序有差..