最近在看《 MySQL 深入浅出》这本书,里面提到了几个 InnoDB 表批量导入数据时的一些优化方案,按照书上的演示来看确实有效,但我实际测试发现,几乎没有效果,不知道是哪里出了问题。
测试数据是导入 102w 条数据,表结构、存储引擎与例子一致,MySQL 版本是 5.7.30
方法 1:导入数据前执行 SET UNIQUE_CHECKS = 0 ,关闭唯一性校验;在导入数据后执行 SET UNIQUE_CHECKS = 1 ,恢复唯一性校验,可以提高导入的效率。
书中效果:关闭前耗时 22.92s 关闭后降低为 19.92s
测试效果:关闭前耗时 26.07s 关闭后耗时:25.70s
多次测试,耗时的差异几乎都差不多,并没有书中 3 秒这么大的差异
方法 2:在导入前执行 SET AUTOCOMMIT = 0
,来关闭自动提交,导入结束后再打开自动提交,也可以提高导入效率
书中效果:关闭前耗时 22.92s 关闭后降低为 20.87s
测试效果:关闭前耗时 25.18s 关闭后耗时:25.04s
也是经过多次测试的效果,书中的例子也是 5.7 的版本。 不太清楚导致这个结果的原因是 MySQL 版本差异还是其他什么原因?
1 GM 2022-02-14 09:26:55 +08:00 ![]() 有没有可能作者测试的时候是 HDD ,你是 SSD ? |
![]() | 2 markgor 2022-02-14 10:02:13 +08:00 ![]() 这个是相对的,而不是绝对的。 比如 SET UNIQUE_CHECKS = 0 ,关闭唯一性校验; 如果作者测试的时候瓶颈大部分是 CPU 进行检验,而你测试的时候 CPU 并非瓶颈,那就会出现 你测试的效率和作者测试的效率不一样。 这就是调优存在的意义,并不是把配置复制黏贴就完事,而是根据实际情况找到瓶颈所在,再进行优化。 |
![]() | 3 maocat 2022-02-14 10:27:38 +08:00 via iPhone 数据量再大一点,再试试 |
![]() | 4 eW91IHNlSBtZQ 2022-02-14 10:33:23 +08:00 @GM 从他的测试结果看,不太可能 |
![]() | 5 815979670 OP |
6 DinnyXu 2022-02-14 11:02:01 +08:00 要考虑一个问题,你的 MySQL 部署在哪?比如云服务器 1 核 2G 的 MySQL 性能如何? 你电脑 4 核 8G MySQL 性能又如何? |
![]() | 7 815979670 OP @DinnyXu 没有在云服务器上测试过,只是在本地测试的,我认为在 同一台机器上 如果配置项是唯一的变量,其他不变的情况下 前后还是有对比性的 |
![]() | 8 yulgang 2022-02-14 13:10:43 +08:00 感觉你也是有效果的,书中的也不那么明显。 |
9 DinnyXu 2022-02-14 16:30:51 +08:00 @815979670 这个也不一定,因为看你测试的数据和书上的数据秒数相差也就是 2-3 秒内。2-3 秒的波动哪怕是你自己的电脑,同样的数据操作 2 次波动也会不一样,就好比一段 select 语句每次查询返回的时间都不一样,要考虑时间和空间的复杂度 |
10 Chinsung 2022-02-14 17:29:19 +08:00 个人感觉 begin; insert…… |
12 keke88168 2022-02-14 17:32:04 +08:00 非要方案,那: sync_binlog innodb_flush_log_at_trx_commit 调成双 0 。 |
![]() | 13 opengps 2022-02-14 20:34:10 +08:00 有些环境因素会导致差异比如磁盘分区时候的块大小 |
14 littlewing 2022-02-14 21:11:00 +08:00 表结构、存储引擎与例子一致,MySQL 版本是 5.7.30 MySQL 版本一致吗? 配置一致吗? |
![]() | 15 815979670 OP @littlewing 表结构 、存储引擎 MySQL 版本(都是 5.7 ,第三位不一致),电脑配置与书中的例子不一致 |
16 littlewing 2022-02-15 10:58:09 +08:00 @815979670 不是电脑配置,是 MySQL 配置 |
![]() | 17 815979670 OP @littlewing 其他更深入的配置都是保持默认,在测试的这几个配置项上,与例子保持一致 |