我正在寻找一些有MySQL专业知识的人的帮助。我不需要一个确切的解决方案 - 只需要一些想法和地点来寻找优化。
关于这个问题的一点点：
好的，所以有了这些特性，我每小时写入数据库的吞吐量大约为100万行。这是大约1 GB的数据或大约300 KB /秒，基于连续多少数据的高端。
但是，当我查看我的机器统计信息时，我注意到磁盘的I / O图以大约20 MB /秒的速度写入扁平线，这表明我受I / O限制。 （CPU图也可以达到100％，但大约90％是iowait）。所以，我的问题是，当通过查询发送的数据量大约为5 KB /秒时，MySQL为什么要向磁盘写入大约20 MB /秒的数据。
我猜这种差异是由于日志文件，临时表和交易倍增 - 但我想知道为什么这个比率接近100：1？如何将这个比例缩小到更合理的水平？什么样的内部变量导致MYSQL将如此多的数据写入磁盘而不是将其存储在内存中？例如，我已经设置了innodb_buffer_pool_size = 12G，max_heap_table_size = 8G和tmp_table_size = 6G，试图让MySQL使用更多内存而不是磁盘 - 但结果仍然相同。
感谢您给我的任何帮助和建议！
答案 0 :(得分：1)
写作的八个主题可能太高或太低，具体取决于您的存储实际情况。
如果您的计算机中有一个旋转金属驱动器，则远太高 - 您的驱动器将全身心地执行写入操作。使用一个帖子。
如果您将数据库表分散到八个或更多SSD驱动器上，这可能没什么问题，但也许更多线程可以让您充分利用极低的“搜索”延迟。 （“Seek”并不真正适用于较新的SSD设备，但我使用的术语与较旧的驱动技术类比。）
答案 1 :(得分：1)
我最好的猜测是，这次90％以上是磁盘搜索。
如果您使用每一行更新索引和事务日志，并且这些事物在物理上彼此远离，则每次写入将导致2-3次搜索。寻道时间约为10ms，它将写入限制为每秒33-50行。这不应该是'加载数据'的情况，因为它避免了事务，但似乎仍然更新索引。如果表空间碎片化，结果可能会更糟。几个并发的线程进一步恶化了这种情况。
尝试在加载期间禁用索引。尝试使用更少的线程，可能只使用一个。
免责声明：我不确切知道'加载数据'是如何工作的; docs from mysql.com根本没有提及交易。