mysql - 为什么 mysql import tablespace 在 insert/update sql 压力下这么慢？

Question

我的 mysql 中有模式 A 和 B，当我对模式 A 进行压力测试时，其中包括大量并发批量插入和更新 sql 操作，并从 xtrabackup 在模式 B 上导出的文件中导入许多表空间。我发现导入操作非常缓慢并且花费大量时间(超过一个小时)。如果我不对schema A做压测，导入操作也就20秒左右。


show processlist:
856 guest 10.142.90.17:51671 pinc_0002 Query 733 Table lock alter table bill import tablespace 0
857 guest 10.142.90.17:51700 pinc_0002 Query 733 Table lock alter table company import tablespace 0
858 guest 10.142.90.17:51731 pinc_0002 Query 733 Table lock alter table car_new import tablespace 0
859 guest 10.142.90.17:51758 pinc_0002 Query 733 Table lock alter table dialing_his import tablespace 0
860 guest 10.142.90.17:51799 pinc_0002 Query 733 Table lock alter table car import tablespace 0
861 guest 10.142.90.17:51846 pinc_0002 Query 732 Table lock alter table employee_his_new import tablespace 0
862 guest 10.142.90.17:51869 pinc_0002 Query 732 Table lock alter table book import tablespace 0
863 guest 10.142.90.17:51914 pinc_0002 Query 732 Table lock alter table goods import tablespace 0
864 guest 10.142.90.17:51975 pinc_0002 Query 732 Table lock alter table order_details import tablespace 0


result of SHOW ENGINE INNODB STATUS


select * from information_schema.INNODB_LOCKS:
115155367:9417:4:2 115155367 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115153055:9417:4:2 115153055 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115150974:9417:4:2 115150974 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF
115148337:9417:4:2 115148337 X RECORD `pinc_0003`.`testcolumn` GEN_CLUST_INDEX 9417 4 2 0x00001D331DDF


result of select * from information_schema.INNODB_TRX


top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND<br/>
54996 apps 20 0 111g 71g 8664 S 1794.7 14.2 2254:20 mysqld
iostat -dxm:```[apps@cs1n3 ~]$ iostat -dxm 2Linux 2.6.32-358.el6.x86_64 (cs1n3) 02/08/2017 _x86_64_ (64 CPU)

设备:rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util标准差 0.04 485.19 8.12 76.89 0.19 2.43 63.20 0.19 2.25 0.16 1.38sdb 0.00 8.14 0.03 2.44 0.00 0.04 35.10 0.01 4.51 0.14 0.04

设备:rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util标准差 0.00 841.50 0.00 7003.50 0.00 63.91 18.69 3.13 0.45 0.13 94.20深发展 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00```

```iostat -dxmLinux 2.6.32-358.el6.x86_64 (cs1n3) 02/08/2017 _x86_64_ (64 CPU)设备:rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util标准差 0.04 485.19 8.12 76.89 0.19 2.43 63.20 0.19 2.25 0.16 1.38sdb 0.00 8.14 0.03 2.44 0.00 0.04 35.10 0.01 4.51 0.14 0.04

设备:rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util标准差 0.00 841.50 0.00 7003.50 0.00 63.91 18.69 3.13 0.45 0.13 94.20深发展 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00```

Answer 1

也许答案就在您的表格架构中。如果您的表中有 PRIMARY_KEY，则您的数据库具有 B-Tree 结构，但如果您的表没有 PRIMARY_KEY，则您的数据库具有 >表结构。所以，也许你的数据库中有 table 结构，所以操作添加/更新比 B-Tree 结构花费更多。