免责声明，我不负责管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/cn.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