mysql 批量插入guid_mysql – GUID与自动增量插入性能

我正在测试具有大量数据的表中自动增量整数与GUID(v4)之间的插入性能.在blog post之后,我期待看到差异.但是现在有超过600万行,我认为没有任何区别.这些是我的表的定义：

自动递增

CREATE TABLE `auto` (

`id` BIGINT(20) NOT NULL AUTO_INCREMENT,

PRIMARY KEY (`id`))

GUID

CREATE TABLE `guid` (

`id` CHAR(32) NOT NULL,

PRIMARY KEY (`id`))

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

我的硬件：Mac mini i5 2.3 GHz,16GB Ram,960GB SSD,但脚本运行在Fusion虚拟机上,配备4GB Ram和Windows 10 x64,MySql服务器安装在虚拟机上.

MySql版本：5.7

那么,我错过了什么吗？我需要更多数据吗？

提前致谢.

解决方法:

您缺少的是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不再足够大之前,您不会注意到性能受到太大影响.然后事情逐渐打击了粉丝.

让我们把东西带得更远……让我们说缓冲区可以容纳1M整数,但是有20M条目.当要插入下一行时,它具有1M / 20M的可能性,即所需的块当前缓存在buffer_pool中.也就是说,只有5％.或者,“错过”的几率为95％ – 几乎总是需要磁盘命中. I / O是SQL缓慢的主要原因.

底线：如果你有一个巨大的表,guids会杀死性能,无论是PRIMARY KEY还是其他索引.

标签：mysql,primary-key,performance-testing,uuid,auto-increment

来源： https://codeday.me/bug/20190806/1602865.html