首页 > 数据库> 文章详细

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

2019-08-06 20:16:30 阅读：331 来源： 互联网

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

我正在测试具有大量数据的表中自动增量整数与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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

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