GUID与自动增量插入性能

Question

我正在测试包含大量数据的表中自动增量整数与GUID (v4)之间插入的性能。遵循这个博客帖子，我期待看到一个不同的。但现在有600多万行，我看不出有什么不同。以下是我的表格的定义：

自动增量

CREATE TABLE `auto` (
    `id` BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (`id`))

参考线

CREATE TABLE `guid` (
`id` CHAR(32) NOT NULL,
PRIMARY KEY (`id`))

代码与引用的博客文章相同，在一个事务中多次插入100 K行。正如我之前说过的，有600多万行，性能没有差别，实际上是一样的。我想找出原因。脚本在C# y中，GUID正在应用程序中生成(而不是在MySql中)。更明确的是，我所做的是从1到1M的for循环，将插入发送到DB，每次我到达100 K行时，提交事务并测量提交时所用的时间。

我的硬件: machine i5 2.3 GHz，16 4GB，960 4GB，但是脚本运行在一个带有4GB Ram的带有Windows10 x64的虚拟机上，MySql服务器上安装在虚拟机上。

MySql版本: 5.7

那么，我是不是遗漏了什么？我需要更多的数据吗？

提前谢谢。

Answer 1

您所缺少的是innodb_buffer_pool_size的设置(假设您使用的是InnoDB)，以及它与id上索引大小的比较。需要“更多的数据”：

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW TABLE STATUS LIKE 'guid';

• 当id是AUTO_INCREMENT或某种“递增”时间戳时，所有工作都将在索引的“最后”块上完成。因此，很少需要缓存以避免I/O。
• 当id是uuid/guid/md5/etc时，使用的缓存空间(buffer_pool)随着表的增长而增加。这是因为id是“随机”跳来跳去的。在buffer_pool不再足够大之前，您不会注意到对性能的影响。后来，事情渐渐地引起了人们的注意。

我们把东西搬得更远..。假设buffer_pool可以容纳100万个实体，但有2000万个条目。当插入下一行时，它有1M/20M的机会，当前所需的块被缓存在buffer_pool中。即只有5%。或者，95%的机会“错过”--几乎总是需要一次磁盘命中。I/O是导致SQL延迟的主要原因。

更多讨论：http://mysql.rjweb.org/doc.php/uuid

底线:如果您有一个巨大的表，无论是PRIMARY KEY还是其他索引，guids都会破坏性能。