MySQL批量SQL插入各种性能优化

对于一些数据量较大的系统。数据库面临的问题除了查询效率低下,还有就是数据入库时间长。特别像报表系统,每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久。因此。优化数据库插入性能是非常有意义的。

经过对MySQL innodb的一些性能測试,发现一些能够提高insert效率的方法。供大家參考參考。

1、一条SQL语句插入多条数据。

经常使用的插入语句如:

INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`)
VALUES (‘0‘, ‘userid_0‘, ‘content_0‘, 0);

INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`)
 VALUES (‘1‘, ‘userid_1‘, ‘content_1‘, 1);

改动成:

INSERT INTO `insert_table` (`datetime`,`uid`,`content`,`type`)
VALUES (‘0‘,‘userid_0‘,‘content_0‘,0),(‘1‘,‘userid_1‘,‘content_1‘,1);

改动后的插入操作能够提高程序的插入效率。这里另外一种SQL运行效率高的主要原因是合并后日志量(MySQL的binlog和innodb的事务让日志)降低了。降低日志刷盘的数据量和频率。从而提高效率。通过合并SQL语句。同一时候也能降低SQL语句解析的次数,降低网络传输的IO。

这里提供一些測试对照数据。各自是进行单条数据的导入与转化成一条SQL语句进行导入,分别測试1百、1千、1万条数据记录。

2、 在事务中进行插入处理。

把插入改动成:

START TRANSACTION;
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`)
   VALUES (‘0‘, ‘userid_0‘, ‘content_0‘, 0);
INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`)
    VALUES (‘1‘, ‘userid_1‘, ‘content_1‘, 1);
...
COMMIT;

使用事务能够提高数据的插入效率,这是因为进行一个INSERT操作时,MySQL内部会建立一个事务,在事务内才进行真正插入处理操作。通过使用事务能够降低创建事务的消耗,全部插入都在运行后才进行提交操作。

这里也提供了測试对照,各自是不使用事务与使用事务在记录数为1百、1千、1万的情况。

3、数据有序插入。

数据有序的插入是指插入记录在主键上是有序排列,比如datetime是记录的主键:

INSERT INTO `insert_table` (`datetime`,`uid`,`content`,`type`)
VALUES(‘1‘,‘userid_1‘,‘content_1‘,1);

INSERT INTO `insert_table`(`datetime`,`uid`,`content`,`type`)
VALUES(‘0‘,‘userid_0‘,‘content_0‘,0);

INSERT INTO `insert_table`(`datetime`,`uid`,`content`,`type`)
VALUES(‘2‘,‘userid_2‘,‘content_2‘,2);

改动成:

INSERT INTO `insert_table` (`datetime`,`uid`,`content`,`type`)
VALUES(‘0‘,‘userid_0‘,‘content_0‘,0);

INSERT INTO `insert_table` (`datetime`,`uid`,`content`,`type`)
VALUES(‘1‘,‘userid_1‘,‘content_1‘,1);

INSERT INTO`insert_table`(`datetime`,`uid`,`content`,`type`)
VALUES(‘2‘,‘userid_2‘,‘content_2‘,2);

因为数据库插入时。须要维护索引数据,无序的记录会增大维护索引的成本。我们能够參照innodb使用的B+tree索引,假设每次插入记录都在索引的最后面,索引的定位效率非常高,而且对索引调整较小。假设插入的记录在索引中间,须要B+tree进行分裂合并等处理。会消耗比較多计算资源,而且插入记录的索引定位效率会下降,数据量较大时会有频繁的磁盘操作。

以下提供随机数据与顺序数据的性能对照,各自是记录为1百、1千、1万、10万、100万。

从測试结果来看。该优化方法的性能有所提高,可是提高并非非常明显。

性能综合測试:

这里提供了同一时候使用上面三种方法进行INSERT效率优化的測试。

从測试结果能够看到,合并数据+事务的方法在较小数据量时,性能提高是非常明显的,数据量较大时(1千万以上)。性能会急剧下降,这是因为此时数据量超过了innodb_buffer的容量,每次定位索引涉及较多的磁盘读写操作。性能下降较快。而使用合并数据+事务+有序数据的方式在数据量达到千万级以上表现依然是良好,在数据量较大时。有序数据索引定位较为方便,不须要频繁对磁盘进行读写操作,所以能够维持较高的性能。

注意事项:

1、SQL语句是有长度限制,在进行数据合并在同一SQL中务必不能超过SQL长度限制。通过max_allowed_packet配置能够改动,默认是1M,測试时改动为8M。

2、事务须要控制大小。事务太大可能会影响运行的效率。MySQL有innodb_log_buffer_size配置项,超过这个值会把innodb的数据刷到磁盘中。这时,效率会有所下降。

所以比較好的做法是,在数据达到这个这个值前进行事务提交。

时间: 2024-10-20 19:41:17

MySQL批量SQL插入各种性能优化的相关文章

MySQL批量SQL插入性能优化

对于一些数据量较大的系统,数据库面临的问题除了查询效率低下,还有就是数据入库时间长.特别像报表系统,每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久.因此,优化数据库插入性能是很有意义的.经过对MySQL innodb的一些性能测试,发现一些可以提高insert效率的方法,供大家参考参考. 1. 一条SQL语句插入多条数据.常用的插入语句如: INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUE

MySQL批量SQL插入性能优化详解

对于一些数据量较大的系统,数据库面临的问题除了查询效率低下,还有就是数据入库时间长.特别像报表系统,每天花费在数据导入上的时间可能会长达几个小时或十几个小时之久.因此,优化数据库插入性能是很有意义的.经过对MySQL innodb的一些性能测试,发现一些可以提高insert效率的方法,供大家参考参考.1. 一条SQL语句插入多条数据.常用的插入语句如: INSERT INTO `insert_table` (`datetime`, `uid`, `content`, `type`) VALUES

SQL点滴22—性能优化没有那么神秘

原文:SQL点滴22-性能优化没有那么神秘 经常听说SQL Server最难的部分是性能优化,不禁让人感到优化这个工作很神秘,这种事情只有高手才能做.很早的时候我在网上看到一位高手写的博客,介绍了SQL优化的问题,从这些内容来看,优化并不都是一些很复杂的问题,掌握了基本的知识之后也可以尝试优化自己的SQL程序,甚至是其他相关的程序.优化是一些工作积累之后的经验总结和代码意识,只要平时注意积累,你也可以做优化的工作.这一篇随笔是转载,不过我强烈推荐给所有对数据库优化有兴趣的博友,读了这一篇之后下一

SQL Server数据库性能优化之SQL语句篇(转载)

SQL Server数据库性能优化之SQL语句篇 原文地址:http://www.blogjava.net/allen-zhe/archive/2010/07/23/326927.html 期项目需要,做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化 前言: 很多人都认为性能是在通过编写代码(程序代码或者是数据库代码)的过程中优化出来的,其实这是一个非常大的误区.真正影响性能最大的部分是在设计中就已经产生了的,后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已,而且能够解决的问题通常也比较有限.本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效,尽可能减少后期的烦恼. 9.1 高效的模型设计 最规范的就一定

SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用

原文:SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用 近段时间以来,一直在探究SQL Server查询性能的问题,当然也漫无目的的查找了很多资料,也从网上的大神们的文章中学到了很多,在这里,向各位大神致敬.正是受大神们无私奉献精神的影响,所以小弟也作为回报,分享一下关于SET STATISTICS IO和SET STATISTICS TIME这两条T_SQL命令,在查询优化性能中的作用. 首先我想说明一下这篇文章不是关于如何

SQL Server 查询性能优化 相关文章

来自: SQL Server 查询性能优化——堆表.碎片与索引(一) SQL Server 查询性能优化——堆表.碎片与索引(二) SQL Server 查询性能优化——覆盖索引(一) SQL Server 查询性能优化——覆盖索引(二) SQL Server 查询性能优化——创建索引原则(一) SQL Server 查询性能优化——创建索引原则(二) SQL Server 查询性能优化——索引与SARG(一) SQL Server 查询性能优化——索引与SARG(二) SQL Server 查

SQL Server数据库性能优化之SQL语句篇

SQL Server数据库性能优化之SQL语句篇 近期项目需要,做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主要讲到如何改善SQL语句,还将有另一篇讨论如何改善索引.如何改善SQL语句的一些原则: 1. 按需索取字段,跟“SELECT *”说拜拜

Sql Server查询性能优化之走出索引的误区

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的