1 insert...from的问题

insert … select 是很常见的在两个表之间拷贝数据的方法。需要注意，在可重复读隔离级别下，这个语句会给

select的表里扫描到的记录和间隙加读锁。

以下对insert...select 进行一下测试

全表读或主键排序读

sessionA

mysql> insert into trajectory_min_section_0511_copy select * from trajectory_min_section_0511;

sessionB

mysql> show engine innodb status;

1451 lock struct(s), heap size 155856, 121231 row lock(s), undo log entries 119783

mysql> show engine innodb status;

3088 lock struct(s), heap size 303312, 258340 row lock(s), undo log entries 255254

mysql> show engine innodb status;

15004 lock struct(s), heap size 1466576, 1256305 row lock(s), undo log entries 1241304

终止sessionA后

sessionB

mysql> show engine innodb status;

ROLLING BACK 23737 lock struct(s), heap size 2302160, 1987628 row lock(s), undo log entries 471818

mysql> show engine innodb status;

ROLLING BACK 23737 lock struct(s), heap size 2302160, 1987628 row lock(s), undo log entries 20019

通过测试可以看到row locks是一个慢慢增长的过程。undo log entries也在一直增长，这个的作用是为了rollback恢复。

用主键升序插入以及用主键降序插入:

select * from trajectory_min_section_0511 order id(PK) ASC

select * from trajectory_min_section_0511 order id(PK) DESC

也是一样的效果，感兴趣的可以测试一下。

从上面测试可知：通过主键排序或则不加排序字段的导入操作"insert into A select * from B"，是会锁B表，但他的锁是逐步地锁定已经扫描过的记录。

当终止后可以看到undo log entries数量慢慢降下去

非主键排序读

sessionA

mysql> insert into trajectory_min_section_0511_copy select * from trajectory_min_section_0511 order by t_distance desc;

sessionB

sessionA执行过程中执行n次

mysql> show engine innodb status;

63595 lock struct(s), heap size 6168784, 5325513 row lock(s), undo log entries 5118624

从上面测试可知：非主键排序的导入操作，是会锁表，而且糟糕的是，锁是一开始就会锁定整张表。

读写验证

sessionA

mysql> insert into trajectory_min_section_0511_copy select * from trajectory_min_section_0511;

sessionB

mysql> select * from trajectory_min_section_0511 where id=1715

搜索靠前主键数据可以正常返回

mysql> update trajectory_min_section_0511 set direction=2 where id=1715

更新靠前主键数据超时无法返回

sessionA

mysql> insert into trajectory_min_section_0511_copy select * from trajectory_min_section_0511 order by id desc;

sessionB

mysql> select * from trajectory_min_section_0511 where id=9999

搜索靠后主键数据可以正常返回

mysql> update trajectory_min_section_0511 set direction=2 where id=1715

更新靠后主键数据超时无法返回

以上测试在上锁过程中，不能dml操作任何被上锁的行，直到锁释放。

如果已知对源表的扫描行数和加锁范围很小的话，简单地使用insert … select 语句即可实现。如果对线上重点表迁移，为了避免对源表加读锁，更稳妥

的方案是先将数据写到外部文本文件，然后再写回目标表。

2 高效加载数据

提高写入、加载速度的几个原则，这些原则在任何数据库上都是通用的：

把数据从缓存刷新到磁盘次数越少，数据加载的越快。因此，批量加载一定是比单条加载效率更高，因为批量插入的行可以先行缓存，然后在

加载操作时候一次性刷到磁盘上，减少磁盘的随机读操作。

表的索引越少，加载速度越快，如果表有多个列存在索引，每次插入都需要更新所有索引完后才会识别到新的行加入。所以不要建无谓的索引。

短sql比长sql加载速度更快，因为在服务器上解析操作耗时更少，并且可以更快的通过网络发送到服务器。

加载数据一般有insert和load两种，接下来详细解读一下底层实现的不同。

2.1 load主备同步流程

主库执行完成后，将/root/table.txt文件的内容直接写到一个外部文件中。

往binlog文件中写入语句load data local infile ‘/tmp/SQL_LOAD_MB-1-0’ INTO TABLE db2.t。

读取本地文件

把这个binlog日志传到备库。

备库的apply线程在执行这个事务日志时：

先将binlog中t.csv文件的内容读出来，写入到本地临时目录/tmp/SQL_LOAD_MB-1-0 中；

再执行load data语句，往备库的db2.t表中插入跟主库相同的数据。

147d3f6f.png

2.2 总结

总的来说，根据官方介绍load可以快出insert 20多倍

load 的底层实现的优化：

1 跳过sql解析，直接生成数据文件;

2 在导入之前会关掉索引，导入完成后更新索引；而与之对比的Insert的处理机制是:每插入一条则更新一次数据库,更新一次索引。

官网的一些解答

f01fa40b.png

4 数据拷贝方法

介绍三种mysql数据拷贝的主流方法，分别是mysqldump(sql语句拷贝)、load(csv文件拷贝)、以及物理文件拷贝。

4.1 mysql dump

mysqldump -h$host -P$port -u$user --add-locks=0 --no-create-info --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --result-file=/client_tmp/t.sql

主要参数含义如下：

–single-transaction的作用是，在导出数据的时候不需要对表db1.t加表锁，而是使用START TRANSACTION WITH CONSISTENT SNAPSHOT的方法；

–add-locks设置为0，表示在输出的文件结果里，不增加" LOCK TABLES t WRITE;" ；

–no-create-info的意思是，不需要导出表结构；

–set-gtid-purged=off表示的是，不输出跟GTID相关的信息；

–result-file指定了输出文件的路径，其中client表示生成的文件是在客户端机器上的。

通过这条mysqldump命令生成的t.sql文件中就包含了如图1所示的INSERT语句。

ae0f129a.png

可以看到一个insert中包含多个value对，这样插入执行速度可以加快。

这也是navicat 上 data transfer功能

148c3bcb.png

4.2 load

show variables like ‘%secure_file_priv%’;

如果设置为empty，表示不限制文件生成的位置，这是不安全的设置；

如果设置为一个表示路径的字符串，就要求生成的文件只能放在这个指定的目录，或者它的子目录；

如果设置为NULL，就表示禁止在这个MySQL实例上执行select … into outfile 操作。

通过修改配置文件永久生效

4f4991f4.png

设置后可以通过命令导出

select * from db1.t where a>900 into outfile '/server_tmp/t.csv';

导出的csv文件可以用如下命令导入

load data infile '/server_tmp/t.csv' into table db2.t;

拷贝到数据库本地后，可以用本地导入，比远程导入更快，因为省去了在load这个事务中网络传输，减轻数据库压力。

load data local infile '/server_tmp/t.csv' into table db2.t;

4.3 物理拷贝

在掌握了逻辑拷贝的方法后，是否有物理导数据的方法呢？比如，直接把db1.t表的.frm文件和.ibd文件拷贝到db2目录下，是否可行呢？

答案是不行的。

因为，一个InnoDB表，除了包含这两个物理文件外，还需要在数据字典中注册。直接拷贝这两个文件的话，因为数据字典中没有db2.t这个表，系统是不会识别和接受它们的。

不过，在MySQL 5.6版本引入了可传输表空间(transportable tablespace)的方法，可以通过导出+导入表空间的方式，实现物理拷贝表的功能。

假设我们现在的目标是在db1库下，复制一个跟表trajectory_min_section_0511相同的表trajectory_min_section_0511_copy，具体的执行步骤如下：

-- 源端执行

flush table trajectory_min_section_0511 for export

这时候数据库目录下会生成一个trajectory_min_section_0511.cfg文件；

cp trajectory_min_section_0511.ibd trajectory_min_section_0511_copy.ibd；

在db1目录下执行cp trajectory_min_section_0511.cfg trajectory_min_section_0511_copy.cfg; 这两个命令(

这里需要注意的是，拷贝得到的两个文件，MySQL进程要有读写权限)；

unlock tables

trajectory_min_section_0511.cfg文件会被删除；

-- 目标端执行

create table trajectory_min_section_0511_copy like trajectory_min_section_0511;

首先创建一个相同表结构的空表

alter table trajectory_min_section_0511_copy discard tablespace;

这时候trajectory_min_section_0511_copy.ibd文件会被删除

alter table trajectory_min_section_0511_copy import tablespace

将这个trajectory_min_section_0511_copy.ibd文件作为表trajectory_min_section_0511_copy的新的表空间，

由于这个文件的数据内容和trajectory_min_section_0511.ibd是相同的，所以表trajectory_min_section_0511_copy中

就有了和表trajectory_min_section_0511相同的数据。

测试后最后一步导入500w耗时10s左右，其他操作都是立刻执行

7c9e2e74.png

几点注意：

在第3步执行完flush table命令之后，整个表trajectory_min_section_0511处于只读状态，直到执行unlock tables命令后才释放读锁；

在执行import tablespace的时候，为了让文件里的表空间id和数据字典中的一致，会修改trajectory_min_section_0511_copy.ibd的表空间id。

而这个表空间id存在于每一个数据页中。因此，如果是一个很大的文件(比如TB级别)，每个数据页都需要修改，import语句的执行是需要一些时间的。

当然，如果是相比于逻辑导入的方法，import语句的耗时是非常短的。

4.4 三种方式对比

对比一下这三种方法的优缺点。

物理拷贝的方式速度最快，尤其对于大表拷贝来说是最快的方法。如果出现误删表的情况，用备份恢复出误删之前的临时库，然后再把临时库中的表拷贝到生产库上，是恢复数据最快的方法。但是，这种方法的使用也有一定的局限性：

a) 必须是全表拷贝，不能只拷贝部分数据；

b) 需要到服务器上拷贝数据，在用户无法登录数据库主机的场景下无法使用；

c) 由于是通过拷贝物理文件实现的，源表和目标表都是使用InnoDB引擎时才能使用。

用mysqldump生成包含INSERT语句文件的方法，可以在where参数增加过滤条件，来实现只导出部分数据。这个方式的不足之一是，不能使用join这种比较复杂的where条件写法。

用select … into outfile的方法是最灵活的，支持所有的SQL写法。但，这个方法的缺点之一就是，每次只能导出一张表的数据，而且表结构也需要另外的语句单独备份。

后两种方式都是逻辑备份方式，是可以跨引擎使用的。

5 当数据量很大时

抛开最后一种物理拷贝，因为在线上时不一定可以登录数据库主机，而且也可能只拷贝部分数据。那一般就是使用load data infile方式导入。

当数据量极大(10+G,千万级别)时，用之前介绍的方式会有很大问题。

load为一个长事务，最后commit后才插入数据库。

undo增长快速，无法回收。数据库性能下降，undo大小大于buffer pool，就会开始内存和磁盘的交换。

可以大文件拆小，监控cpu后，在合理的利用率情况下，多线程load。

6 扩展知识点

针对并发场景的一致性问题，第一个能想到的是加锁，但是数据库中所有操作都上锁势必会带来性能的低下，mysql的隔离级别(isolation level)最高级叫串行化，

其设计上可以认为就是加一把大锁，读的时候加共享锁，不能写，写的时候，加的是排它锁，阻塞其它事务的写入和读取，若是其它的事务长时间不能写入就会直接报超时，所以它的性能也是最差的，对于它来就没有什么并发性可言。

在InnoDB 的读提交和可重复读两种级别都使用了多版本并发控制模型(MVCC)

比如在实现可重复读的隔离级别，只需要在事务开始的时候创建一致性视图，也叫做快照，之后的查询里都共用这个一致性视图，后续的事务对数据的更改

是对当前事务是不可见的，这样就实现了可重复读。 中每一个事务都有一个自己的事务id，并且是唯一的，递增的 。

71a299d8.png

最开始数据的版本是V0；

T1时刻发起了一个写任务，这是把数据clone了一份，进行修改，版本变为V1，但任务还未完成；

T2时刻并发了一个读任务，依然可以读V0版本的数据；

T3时刻又并发了一个读任务，依然不会阻塞；

对于Mysql中的每一个数据行都有可能存在多个版本，在每次事务更新数据的时候，都会生成一个新的数据版本，并且把自己的数据id赋值给当前版本的row trx_id。

e6536994.png

如图中所示，假如三个事务更新了同一行数据，那么就会有对应的三个数据版本。

实际上版本1、版本2并非实际物理存在的，而图中的U1和U2实际就是undo log，这v1和v2版本是根据当前v3和undo log计算出来的。

当出现事务回滚的时候，通过undo log反向重现redo log的过程，就可以将当前数据回退回事务开始前数据状态。

当事务提交后undo块就会慢慢的回收。要避免长事务，因为如果长事务中有更新，就意味着占用着行锁，导致别的语句更新被锁。还有读的事务会导致undo log不能回收，导致回滚段空间膨胀。

扩展阅读 万字长文，帮你梳理存储引擎之Heap表关键知识点