我有一个进程，每个服务器打开60个Iframe窗口，每个窗口都执行部分任务。 mysql表未编入索引，数据在批量插入中一次插入1000行（首先写入每帧中创建的临时内存，然后批量卸载到hd表）。这是每个表处理15亿行数据，由32核128g RAM服务器运行的60帧写入，它将服务器CPU最大化为99-100％，持续6-7小时。我有3个服务器处理这个任务，还有1个在raid上有24个驱动器作为数据库服务器，它只运行6-15％的CPU负载来管理mysql（5.0.67）。从1到3台服务器处理数据的瓶颈在哪里发生，不会增加写入的“总”数据？ 3中的每一个都写入1 db表，表锁是最小的，我可以将它翻转到每个帧写入1表消除锁但我不认为这是问题考虑180连接连续写只相当于每秒5-10次锁定。删除索引确实大大加快了写入速度，（一旦写完所有数据，我将不得不处理）。有没有mysql值/选项/？这将改善这一点，我还有160个表可以创建吗？我希望我可以使用Ram表，但是每个表的数据本身就是33 gig而mysql 5.0.67不会这样做，切换到5.6的任何东西都是巨大的差异吗？我很难过，mysql说它写的是avg 47 mb / s，密钥效率= 100％，查询缓存命中率= 93 - 100％。非常感谢任何帮助，谢谢大家的任何意见。
答案 0 :(得分：2)
你是否同时打开了60个iframe？
这意味着所有流程都是并行的。事情不会像这样变得更快，而是放慢速度。
某个地方的瓶颈与从磁盘读取表有关。乘以并发磁盘访问正在减慢一切。甚至没有谈论可能在数据库服务器中相互阻塞的同时长期运行的查询。
比较写入这些值的47 Mb / s：
你很接近