免责声明，我不负责管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 真的调得很好