转自:https://www.cnblogs.com/myseries/p/11191134.html
1.批量insert
1.1 一条sql
将单条insert改为批量insert,其实个人认为改为replace into更好,批量insert时,如果其中一条主键重复了,那么就会报错后面的insert不会再执行,因为整体是一条sql语句,是一个事务,ACID。
修改后的插入操作能够提高程序的插入效率。这里第二种SQL执行效率高的主要原因是:
- 通过合并SQL语句,同时也能减少SQL语句解析次数,减少了数据库连接的I/O开销,一般会把多条数据插入放在一条SQL语句中一次执行;
- 合并后日志量(MySQL的binlog和innodb的事务让日志)减少了,降低日志刷盘的数据量和频率,从而提高效率。
批量插入可能数据量太大,可查看:
mysql> show VARIABLES like '%max_allowed_packet%'; +--------------------------+------------+ | Variable_name | Value | +--------------------------+------------+ | max_allowed_packet | 134217728 | | slave_max_allowed_packet | 1073741824 | +--------------------------+------------+ 2 rows in set (0.00 sec)
SQL语句是有长度限制
,这里转换后应该是128MB。控制一次批量插入的容量。//sql语句本身就是个字符串,它是限制字符串的长度。
1.2 在事务中插入
主要是通过减少事务的创建次数提高效率。因为进行一个INSERT操作时,MySQL内部会建立一个事务,在事务内才进行真正插入处理操作。通过使用事务可以减少创建事务的消耗,所有插入都在执行后才进行提交操作
。
结果:
注意:事务需要控制大小
,事务太大可能会影响执行的效率。MySQL有innodb_log_buffer_size配置项,超过这个值会把innodb的数据刷到磁盘中,效率会有所下降。所以需要在数据达到这个这个值前进行事务提交。
mysql> show VARIABLES like '%innodb_log_buffer_size%'; +------------------------+----------+ | Variable_name | Value | +------------------------+----------+ | innodb_log_buffer_size | 67108864 | +------------------------+----------+ 1 row in set (0.00 sec)
默认是64MB。
1.3 有序插入
博客还探究了在有索引的主键上顺序插入,因为插入数据时,mysql需要维护索引,无序的记录会增大维护索引的成本:
如果每次插入记录都在索引的最后面,索引的定位效率很高,并且对索引调整较小;
- 如果插入的记录在索引中间,需要B+tree进行分裂合并等处理,会消耗比较多计算资源,并且插入记录的索引定位效率会下降,数据量较大时会有频繁的磁盘操作。
总结:
- 合并数据+事务(随机)的方法在较小数据量时,性能提高是很明显的,数据量较大时(1千万以上),性能会急剧下降,这是由于此时数据量超过了innodb_buffer的容量,每次定位索引涉及较多的磁盘读写操作,性能下降较快。
- 而使用合并数据+事务+有序数据的方式在数据量达到千万级以上表现依旧是良好,在数据量较大时,有序数据索引定位较为方便,不需要频繁对磁盘进行读写操作,所以可以维持较高的性能。
//什么业务场景会一次性插入1千万条数据?想象不出来。
2.单条与事务批量优缺点
- 自动提交事务:
mysql 默认是autocommit=on也就是默认开启自动提交事务。这种情况下,一条sql就会开启一个事务,这时候同时执行一万条update,就会导致实际开启一万个事务,然后挨个执行,挨个开启,挨个提交。
优缺点:同时锁住数据较少,但是数据库资源占用严重,对外提供操作性能急剧下降。//可以理解为每个都要单独提交事务,频繁写日志binlog、redolog等。
- 手动提交事务:
当autocommit=off时,同时执行一万条update,那么只会开启一个事务,等到所有都update后,一并commit。
优缺点:同时锁住数据较多,外面的select进不来,大量连接等待获取行锁,同样影响数据库对外服务能力。
建议:手动分批提交事务。
标签:事务,批量,索引,插入,innodb,数据量,Mysql From: https://www.cnblogs.com/BlueBlueSea/p/16905334.html