mysql load 相關(guān)實(shí)驗(yàn)過程是怎樣的
本篇文章為大家展示了mysql load 相關(guān)實(shí)驗(yàn)過程是怎樣的，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。
一:load 的過程相當(dāng)于是：先start transaction，然后再insert數(shù)據(jù)，最后commit
我猜測(cè)mysql 區(qū)別于oracle sqlldr,沒有后者的rows的參數(shù)來控制每次提交的數(shù)據(jù)行
但是我感覺 mysql 是自己通過估算出一個(gè)值，來批量讀取 ，我覺得他不是 一條一條的 insert的
二：load 如果數(shù)據(jù)存在（主鍵或者唯一鍵），默認(rèn)是跳過的，可以選擇replace存在就替換！
三：load 沒有類似于oracle的 sqlldr的rows參數(shù)來控制每次提交的行數(shù)，只能先通過linux命令來
切分（split）成小文件來實(shí)現(xiàn)并行；
實(shí)驗(yàn)一：load會(huì)不會(huì)鎖表
session1
[root@beijing-fuli-hadoop-04 ~]# cat /data/t.txt
100, liu ,18
102, liu ,18
101, liu, 18
root@localhost : (none) 11:50:05>start transaction;
Query OK, 0 rows affected (0.00 sec)
root@localhost : (none) 11:51:08>LOAD DATA LOCAL INFILE '/data/t.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
Query OK, 3 rows affected (0.03 sec)
Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
然后不commit！
session2
如下全部等待
root@localhost : liuwenhe 11:52:36>delete from t where id=101;
root@localhost : liuwenhe 11:52:36>delete from t where id=102;
root@localhost : liuwenhe 11:52:36>delete from t where id=103;
如下 不等待
delete from t where id=104
delete from t where id=100
結(jié)論：
load 在提交之前，會(huì)鎖定所有剛load的數(shù)據(jù)?。?！也間接的說明這是一個(gè)事務(wù)把三個(gè)數(shù)據(jù)
都load進(jìn)去了，會(huì)不會(huì)是 mysql 默認(rèn)把N行數(shù)據(jù)作為一個(gè)事務(wù)呢？采用大數(shù)據(jù)量來做驗(yàn)證
實(shí)驗(yàn)二：load是不是一個(gè)事務(wù)
1.文件/data/12.txt是26135101行數(shù)據(jù)的文件
2.然后開始load
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/12.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
3.另開一個(gè)會(huì)話，查詢數(shù)據(jù)，發(fā)現(xiàn)再load完成之前一直是空，
root@localhost : liuwenhe 13:55:15>select count(*) from t;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.66 sec)
這就進(jìn)一步說明 load操作是一個(gè)事務(wù)的?。。?/p>
實(shí)驗(yàn)三：是否允許在同一個(gè)表上同時(shí)進(jìn)行l(wèi)oad? 只要沒有沖突是可以并行的！
這里所說的沖突是指: 已經(jīng)load 處理了的數(shù)據(jù)中和另一個(gè)會(huì)話要處理的數(shù)據(jù)有沖突，具體實(shí)驗(yàn)如下：
假如1.txt 文件 是id從1到2147483647這個(gè)范圍的數(shù)據(jù)，而2.txt是id=2147483647的
一條數(shù)據(jù)，而3.txt是id從1到3的范圍并且還有id=2147483646這條數(shù)據(jù)
具體如下：
[root@beijing-fuli-hadoop-04 liuwenhe]# cat 2.txt
26293013,liu ,18
[root@beijing-fuli-hadoop-04 liuwenhe]# cat 3.txt
1, liu ,18
26293013,liu ,18
具體實(shí)驗(yàn)過程：
實(shí)驗(yàn)1）
會(huì)話1：
執(zhí)行這個(gè)，因?yàn)閿?shù)據(jù)量比較大，所以會(huì)執(zhí)行一會(huì)
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/liuwenhe/1.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
會(huì)話2：
[root@beijing-fuli-hadoop-04 liuwenhe]# cat 2.txt
26293013,liu ,18
然后會(huì)話1還沒有結(jié)束呢，執(zhí)行如下操作，發(fā)現(xiàn)沒有等待！確實(shí)進(jìn)去了，
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/liuwenhe/2.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
root@localhost : liuwenhe 17:33:18>select * from t where id =26293013;
+----------+-------+------+
| id | name | num |
+----------+-------+------+
| 26293013 | liu | 18 |
+----------+-------+------+
1 row in set (0.12 sec)
說明：load順序執(zhí)行,當(dāng)執(zhí)行到的id=1的數(shù)據(jù)到達(dá)innodb層，mysql就會(huì)把id=1的數(shù)據(jù)上鎖gap鎖，
這時(shí)候你再load=1的數(shù)據(jù)就會(huì)有鎖等待，但是你沒有執(zhí)行到id=26293013的數(shù)據(jù)，也就沒有給這條數(shù)據(jù)上鎖，所以你并行執(zhí)行另一個(gè)load （id=26293013）的數(shù)據(jù)就不會(huì)等待。
實(shí)驗(yàn)2）
會(huì)話1：
執(zhí)行這個(gè)，因?yàn)閿?shù)據(jù)量比較大，所以會(huì)執(zhí)行一會(huì)
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/liuwenhe/1.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
會(huì)話2：
在會(huì)話1還沒有結(jié)束的時(shí)候，執(zhí)行如下發(fā)現(xiàn)等待，因?yàn)閕d=1的數(shù)據(jù)被會(huì)話1鎖定，所以下面的操作是需要等待的，因?yàn)閘oad 3.txt是先處理id=1的數(shù)據(jù)，但是它已經(jīng)被鎖定了，
[root@beijing-fuli-hadoop-04 liuwenhe]# cat 3.txt
1, liu ,18
26293013,liu ,18
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/3.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
實(shí)驗(yàn)3）load 產(chǎn)生死鎖：
會(huì)話1：
執(zhí)行這個(gè)，因?yàn)閿?shù)據(jù)量比較大，所以會(huì)執(zhí)行一會(huì)；
root@localhost : liuwenhe 13:54:50>LOAD DATA LOCAL INFILE '/data/liuwenhe/1.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
會(huì)話2：
在會(huì)話1還沒有結(jié)束的時(shí)候，執(zhí)行如下發(fā)現(xiàn)等待，因?yàn)閕d=1的數(shù)據(jù)被會(huì)話1鎖定，但是id=26293013的數(shù)據(jù)沒有被鎖定呢，所以說load 4.txt的時(shí)候，能把第一條數(shù)據(jù)（id=26293013）load進(jìn)innodb引擎層并且鎖定，但是1這條數(shù)據(jù)卻被鎖定，進(jìn)而會(huì)話1和會(huì)話2產(chǎn)生鎖等待！
[root@beijing-fuli-hadoop-04 liuwenhe]# cat 4.txt
26293013,liu ,18
1, liu ,18
root@localhost : (none) 18:13:10>LOAD DATA LOCAL INFILE '/data/liuwenhe/4.txt' INTO TABLE liuwenhe.t fields terminated by ',' LINES TERMINATED BY '\n' ;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
注釋：為什么會(huì)選擇回滾會(huì)話2的事務(wù)？因?yàn)槲议_啟了死鎖檢測(cè)，然后數(shù)據(jù)庫選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾
MySQL 如何處理死鎖？
MySQL有兩種死鎖處理方式：
等待，直到超時(shí)（innodb_lock_wait_timeout=50s）。
發(fā)起死鎖檢測(cè)，主動(dòng)回滾一條事務(wù)，讓其他事務(wù)繼續(xù)執(zhí)行（innodb_deadlock_detect=on）。
由于性能原因，一般都是使用死鎖檢測(cè)來進(jìn)行處理死鎖。
死鎖檢測(cè)
死鎖檢測(cè)的原理是構(gòu)建一個(gè)以事務(wù)為頂點(diǎn)、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測(cè)到死鎖之后，選擇插入更新或者刪除的行數(shù)最少的事務(wù)回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
上述內(nèi)容就是mysql load 相關(guān)實(shí)驗(yàn)過程是怎樣的，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。
