我正在测试 Microsoft Azure Database for MySQL，遇到了一个我无法理解的性能问题。
我启动了一台具有 1 个 vCore（2 GB RAM，“标准存储”）的“基本”服务器，这是他们最低级别的服务器。我创建了一个数据库、一个表，并使用 LOAD DATA INFILE 导入了大约 400 万行（30 GB）。这花了 56 分钟。
接下来，我启动了一台具有 8 个 vCore（80 GB RAM，“高级存储”）的“内存优化”服务器。我重复了完全相同的任务并加载了完全相同的文件。这次花了 7 小时 16 分钟。
服务器更好，性能却差很多（在这项任务上）——这不是我所期望的。为了确保我没有犯错，我重复了上述步骤，但我再次得到了几乎完全相同的结果。
我怀疑问题在于内存优化服务器的默认服务器参数与基本服务器不同，这导致此任务的执行速度较慢（我没有更改 Azure 设置的默认参数）。但我不确定哪些参数是罪魁祸首。如果有人对这个问题有见解，我将不胜感激。
基本服务器参数：http://pastebin.zone/wRniyPm6
内存优化服务器参数：http://pastebin.zone/phuDcZj4
答案1
导致这种行为的原因如下：
根据Azure 文档，Azure 上的基本层服务器带有“可变” IOPS，而内存优化服务器带有固定 IOPS，该 IOPS 基于分配给数据库服务器的存储量。
我为内存优化服务器分配了 100GB。这使其具有 300 IOPS，符合 Azure 的 3 IOPS / GB 比率。
据推测，基本服务器上的“可变” IOPS 最终会大大高于内存优化服务器上的 300 IOPS。
经验教训：为了在 Azure 数据库上获得快速存储访问，您需要为您的服务器分配足够的存储容量（即使您不需要那么多存储空间！）。
答案2
当您加载数百万行数据时，请为您的 AWS 参数组提出建议，
innodb_change_buffer_max_size=50 # from 25 for improved LOAD speed during high volume process
完成后，根据您的典型操作需要返回到 25%（或更少）。
在内存增强型实例上，
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
对于下一次测试，这些应该会减少经过的时间。