---

歡迎關注我的《深入理解MySQL主從原理 32講 》

---

###一、pt-online-schema-change 原理簡析

首先要說明pt-online-schema-change工具並不是說修改表結構的時候不上鎖，通常我們說的鎖一般包含innodb 行鎖和MDL lock。而pt-online-schema-change工具就是將某些使用COPY演算法的DDL操作使用DML操作來代替，換句話說就是使用Innodb row鎖來代替MDL lock，因為MySQL原生的COPY演算法的DDL會在MDL lock SNW這個型別保護下完整個表複製操作，整個複製過程中是不允許DML操作，因此造成了我們COPY演算法的DDL堵塞執行緒正常的現象，當然哪些DDL可以online進行可以參考官方文件online ddl一節。整個pt-online-schema-change工具修改過程中，只會在rename階段才會上MDL LOCK的X鎖，但是rename操作一般非常快速。

我們大概看一下pt-online-schema-change的工作方式，這個實際上開啟genrnal log就能看出來下面是重點步驟（我的表名叫做testpt_osc）：

- 首先定義出新表

>CREATE TABLE `test`.`_testpt_osc_new` (
  `id` int(11) NOT NULL,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
ALTER TABLE `test`.`_testpt_osc_new` add index name_index(name)

- 定義三個觸發器

>delete 觸發器：
CREATE TRIGGER `pt_osc_test_testpt_osc_del` 
AFTER DELETE ON `test`.`testpt_osc` 
FOR EACH ROW 
DELETE IGNORE FROM `test`.`_testpt_osc_new` 
WHERE `test`.`_testpt_osc_new`.`id` <=> OLD.`id`

>update 觸發器：
CREATE TRIGGER `pt_osc_test_testpt_osc_upd` 
AFTER UPDATE ON `test`.`testpt_osc` 
FOR EACH ROW 
BEGIN 
DELETE IGNORE FROM `test`.`_testpt_osc_new` 
WHERE !(OLD.`id` <=> NEW.`id`) 
AND `test`.`_testpt_osc_new`.`id` <=> OLD.`id`;
REPLACE INTO `test`.`_testpt_osc_new` (`id`, `name`) VALUES
(NEW.`id`, NEW.`name`);
END

>insert 觸發器：
CREATE TRIGGER `pt_osc_test_testpt_osc_ins` 
AFTER INSERT ON `test`.`testpt_osc` 
FOR EACH ROW 
REPLACE INTO `test`.`_testpt_osc_new` (`id`, `name`) VALUES 
(NEW.`id`, NEW.`name`)

- 使用分塊（chunk）複製的方式

>首先需要插入資料的確認上界：
SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `test`.`testpt_osc` FORCE INDEX(`PRIMARY`) 
WHERE ((`id` >= '1')) ORDERBY `id` LIMIT 1999, 2 /*next chunk boundary*/

>然後插入：
INSERT LOW_PRIORITY IGNORE INTO `test`.`_testpt_osc_new` (`id`, `name`) 
SELECT `id`, `name` FROM `test`.`testpt_osc` FORCE INDEX(`PRIMARY`) 
WHERE ((`id` >= '1')) AND ((`id` <= '2000')) LOCK IN SHARE MODE
 
- 最終進行表的重新命名
>使用RENAME TABLE `test`.`tp1` TO `test`.`_tp1_old`, `test`.`_tp1_new` TO `test`.`tp1`
程式重新命名。

從整個過程來講需要注意的幾個地方：

1. 對於delete和update觸發器來講，delete資料均使用了IGNORE進行修飾，因此即便資料還沒有複製到新表也不會引發錯誤。
2. 對於update和insert觸發器來講，均使用了replace這種操作來進行，因此如果資料還沒有複製到新表那麼將插入到新表中，如果資料已經複製到新表那麼將會修改其中的值。因此新表中總是保留的最新的資料。
3. 對於分塊複製資料而言，使用是insert ignore 新表 select 老表 LOCK S 的方式，因此對於觸發器插入的最新值，是不會進行修改的也不會報錯。打個比方chunk為200 當前複製資料到了1000行，但是我們手動修改了第2000行的資料，那麼第2000行將會在update觸發器的作用下提前插入到新表中，當複製資料來到這一行的時候因為使用了ignore則不會重複行的錯誤，並且資料是最新的。其次每次insert select操作是一個單獨的事務。
4. insert ignore 新表 select 老表 LOCK S 的方式 操作存在對新表中加自增鎖的可能，這取決於你的引數設定。
5. 對於觸發器而言，原始語句和觸發語句被包裹在一個事務裡面，也就是說對於任何一個DML語句而言，修改老表和新表的資料需要的行鎖將會在一個事務中存在。
6. pt-online-schema-change 生成的binlog和redo都會比online DDL大得多，效率上講應該低於online DDL。
7. 由於replace操作的存在，因此pt-online-schema-change將會依賴主鍵或者唯一鍵，否則將不能工作。

我們可以看到整個過程中有如下的重點知識點：
- 觸發器和事務
- Insert ignore/replace語法
- 自增死鎖的發生

其次對於第4和第5點來講，有出現死鎖的可能。下面我們分別討論。

###二、觸發器與事務

在pt-online-schema-change中，觸發器佔據了重要的地位，我們需要了解一下觸發器和事務之間的關係。我們常用的觸發器包含了before和after觸發器，代表著對原表進行DML操作前或者後進行其它的操作，下面是我定義的兩個測試的觸發器如下：
```
CREATE  TRIGGER testbef BEFORE INSERT ON t1
FOR EACH ROW
BEGIN
INSERT INTO t2 values(new.id);
END;

CREATE TRIGGER testaft after INSERT ON t1
FOR EACH ROW
BEGIN
INSERT INTO t3 values(new.id);
END;
```

顯然如果對t1表進行資料插入，那麼會在之前向t2表插入一條資料，然後在之後向t3插入一條資料，這一點可以透過函式呼叫trace進行驗證如下：
```
[root@ora12ctest mysql]#  cat -n tri2.trace |grep row_ins
   970  T@3: | | | | | | | | | | | >row_ins
   971  T@3: | | | | | | | | | | | | row_ins: table: test/t2 向t2表插入資料
...
  1406  T@3: | | | | | | | | >row_ins
  1407  T@3: | | | | | | | | | row_ins: table: test/t1 向t1表插入資料
...
  1779  T@3: | | | | | | | | | | | | >row_ins
  1780  T@3: | | | | | | | | | | | | | row_ins: table: test/t3 向t3表插入資料
...
```

這裡就能夠看到順序了，其次我們還需要知道這些所有的操作會包裹在一個事務裡面，這一點也可以透過函式呼叫trace進行驗證，還可以使用binlog進行驗證，下面是一次呼叫的binlog資訊：

```
# at 194 （這裡是GTID EVENT事務開始）
#200212 17:23:16 server id 1903313  end_log_pos 259 CRC32 0x4ff6735e    GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '92008a52-4b7d-11ea-9ec6-000c29c8aca8:202'/*!*/;
# at 259
#200212 17:23:16 server id 1903313  end_log_pos 331 CRC32 0x1ebd3446    Query   thread_id=3     exec_time=0     error_code=0
...
BEGIN
/*!*/;
# at 331
#200212 17:23:16 server id 1903313  end_log_pos 384 CRC32 0xe748dc3a    Rows_query
# INSERT INTO t2 values(new.id)
# at 384
#200212 17:23:16 server id 1903313  end_log_pos 429 CRC32 0x093c5fe3    Table_map: `test`.`t1` mapped to number 108
# at 429
#200212 17:23:16 server id 1903313  end_log_pos 474 CRC32 0x92691238    Table_map: `test`.`t2` mapped to number 110
# at 474
#200212 17:23:16 server id 1903313  end_log_pos 519 CRC32 0x5b9a710f    Table_map: `test`.`t3` mapped to number 111
# at 519
#200212 17:23:16 server id 1903313  end_log_pos 559 CRC32 0xe41b1119    Write_rows: table id 110
# at 559
#200212 17:23:16 server id 1903313  end_log_pos 599 CRC32 0x36c3511c    Write_rows: table id 108
# at 599
#200212 17:23:16 server id 1903313  end_log_pos 639 CRC32 0xa68b9ae6    Write_rows: table id 111 flags: STMT_END_F
### INSERT INTO `test`.`t2`
### SET
###   @1=11000 /* INT meta=0 nullable=0 is_null=0 */
### INSERT INTO `test`.`t1`
### SET
###   @1=11000 /* INT meta=0 nullable=1 is_null=0 */
### INSERT INTO `test`.`t3`
### SET
###   @1=11000 /* INT meta=0 nullable=0 is_null=0 */
# at 639 （這裡是XID EVENT事務提交）
#200212 17:23:16 server id 1903313  end_log_pos 670 CRC32 0xbbb6547b    Xid = 19
COMMIT/*!*/;
```

這裡我們使用binlog不僅驗證了執行順序並且還驗證了所有操作都包含在一個事務裡面。**既然所有的語句都包裹在一個事務裡面，那麼加鎖的範圍就更大了，這不僅關係到本身的DML操作表，並且還關係到觸發語句的相關表，需要額外注意。**

其次所有語句不僅包裹在一個事務裡面，並且共享一個錯誤返回介面，那麼如下的錯誤：
```
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

mysql> insert into t1 values(1);
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'
mysql>

```
我們驚訝的發現t1表一條資料都沒有，但是居然返回重複的行。**原因就在於雖然t1表沒有資料，但是t2或者t3表有違反唯一性檢查的可能，因此返回了錯誤，錯誤由統一的介面返回給客戶端。**

最後觸發器會導致處理邏輯混亂，**儘量避免使用觸發器**。

###三、Insert ignore/replace語法

關於ignore語法我們以insert ignore語法為例，一般來講如果遇到重複行insert ignore語法會透過忽略重複值錯誤的方式進行跳過，這實際上和replace的處理方式一致，但是replace不同的是如果遇到重複行不是進行忽略，而是執行的delete然後執行insert操作。換句話說他們的觸發形式一致，但是觸發後執行的行為是不同的，下面我們就來看看。

首先對於insert語句來講我們需要定位到需要插入的位置，這部分略過。

#####1、進行重複行判斷操作

這一步對於主鍵/唯一索引 而言需要判斷是否已經有重複的行。其判斷標準基本都是透過插入的值進行索引定位，然後判斷定位遊標的值是否和需要插入值相同，下面是棧幀：

> 主鍵：
```
#0  row_ins_duplicate_error_in_clust (flags=0, cursor=0x7fffec4347d0, entry=0x7367c00, thr=0x7362980, mtr=0x7fffec433fa0)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:2273
#1  0x0000000001ae47d4 in row_ins_clust_index_entry_low (flags=0, mode=2, index=0x73674f0, n_uniq=1, entry=0x7367c00, n_ext=0, thr=0x7362980, dup_chk_only=false)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:2555
#2  0x0000000001ae697a in row_ins_clust_index_entry (index=0x73674f0, entry=0x7367c00, thr=0x7362980, n_ext=0, dup_chk_only=false)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3293
#3  0x0000000001ae6e88 in row_ins_index_entry (index=0x73674f0, entry=0x7367c00, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3429
#4  0x0000000001ae73e2 in row_ins_index_entry_step (node=0x7362710, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3579
#5  0x0000000001ae7749 in row_ins (node=0x7362710, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3717
#6  0x0000000001ae7bae in row_ins_step (thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3853
#7  0x0000000001b05f73 in row_insert_for_mysql_using_ins_graph (mysql_rec=0x736e7a0 "\375\002", prebuilt=0x7362170)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1738
#8  0x0000000001b06484 in row_insert_for_mysql (mysql_rec=0x736e7a0 "\375\002", prebuilt=0x7362170) at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1859
#9  0x00000000019adca9 in ha_innobase::write_row (this=0x736e4b0, record=0x736e7a0 "\375\002") at /mysql/mysql-5.7.26/storage/innobase/handler/ha_innodb.cc:7598
#10 0x0000000000f67dc0 in handler::ha_write_row (this=0x736e4b0, buf=0x736e7a0 "\375\002") at /mysql/mysql-5.7.26/sql/handler.cc:8062
#11 0x00000000017cf173 in write_record (thd=0x6dd5660, table=0x735afa0, info=0x7fffec435b50, update=0x7fffec435ad0) at /mysql/mysql-5.7.26/sql/sql_insert.cc:1873
#12 0x00000000017cc24a in Sql_cmd_insert::mysql_insert (this=0x6debbc8, thd=0x6dd5660, table_list=0x6deb638) at /mysql/mysql-5.7.26/sql/sql_insert.cc:769
#13 0x00000000017d2d7f in Sql_cmd_insert::execute (this=0x6debbc8, thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_insert.cc:3118
#14 0x000000000159a70c in mysql_execute_command (thd=0x6dd5660, first_level=true) at /mysql/mysql-5.7.26/sql/sql_parse.cc:3596
#15 0x00000000015a06c0 in mysql_parse (thd=0x6dd5660, parser_state=0x7fffec437610) at /mysql/mysql-5.7.26/sql/sql_parse.cc:5570
#16 0x0000000001595283 in dispatch_command (thd=0x6dd5660, com_data=0x7fffec437d80, command=COM_QUERY) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1484
#17 0x00000000015940bc in do_command (thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1025
#18 0x00000000016cbf91 in handle_connection (arg=0x6dda360) at /mysql/mysql-5.7.26/sql/conn_handler/connection_handler_per_thread.cc:306
#19 0x0000000001921c64 in pfs_spawn_thread (arg=0x6d7d0f0) at /mysql/mysql-5.7.26/storage/perfschema/pfs.cc:2190
#20 0x0000003823e079d1 in start_thread () from /lib64/libpthread.so.0
#21 0x0000003823ae8b6d in clone () from /lib64/libc.so.6
```

> 二級索引唯一鍵

```
#0  row_ins_scan_sec_index_for_duplicate (flags=0, index=0x7366e10, entry=0x7367ca8, thr=0x7362980, s_latch=false, mtr=0x7fffec434020, offsets_heap=0x7389038)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:2050
#1  0x0000000001ae5d35 in row_ins_sec_index_entry_low (flags=0, mode=2, index=0x7366e10, offsets_heap=0x7389038, heap=0x7368538, entry=0x7367ca8, trx_id=0, 
    thr=0x7362980, dup_chk_only=false) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3033
#2  0x0000000001ae6cea in row_ins_sec_index_entry (index=0x7366e10, entry=0x7367ca8, thr=0x7362980, dup_chk_only=false)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3382
#3  0x0000000001ae6ea6 in row_ins_index_entry (index=0x7366e10, entry=0x7367ca8, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3431
#4  0x0000000001ae73e2 in row_ins_index_entry_step (node=0x7362710, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3579
#5  0x0000000001ae7749 in row_ins (node=0x7362710, thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3717
#6  0x0000000001ae7bae in row_ins_step (thr=0x7362980) at /mysql/mysql-5.7.26/storage/innobase/row/row0ins.cc:3853
#7  0x0000000001b05f73 in row_insert_for_mysql_using_ins_graph (mysql_rec=0x736e7a0 "\375\003", prebuilt=0x7362170)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1738
#8  0x0000000001b06484 in row_insert_for_mysql (mysql_rec=0x736e7a0 "\375\003", prebuilt=0x7362170) at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1859
#9  0x00000000019adca9 in ha_innobase::write_row (this=0x736e4b0, record=0x736e7a0 "\375\003") at /mysql/mysql-5.7.26/storage/innobase/handler/ha_innodb.cc:7598
#10 0x0000000000f67dc0 in handler::ha_write_row (this=0x736e4b0, buf=0x736e7a0 "\375\003") at /mysql/mysql-5.7.26/sql/handler.cc:8062
#11 0x00000000017cf173 in write_record (thd=0x6dd5660, table=0x735afa0, info=0x7fffec435b50, update=0x7fffec435ad0) at /mysql/mysql-5.7.26/sql/sql_insert.cc:1873
#12 0x00000000017cc24a in Sql_cmd_insert::mysql_insert (this=0x6debbc8, thd=0x6dd5660, table_list=0x6deb638) at /mysql/mysql-5.7.26/sql/sql_insert.cc:769
#13 0x00000000017d2d7f in Sql_cmd_insert::execute (this=0x6debbc8, thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_insert.cc:3118
#14 0x000000000159a70c in mysql_execute_command (thd=0x6dd5660, first_level=true) at /mysql/mysql-5.7.26/sql/sql_parse.cc:3596
#15 0x00000000015a06c0 in mysql_parse (thd=0x6dd5660, parser_state=0x7fffec437610) at /mysql/mysql-5.7.26/sql/sql_parse.cc:5570
#16 0x0000000001595283 in dispatch_command (thd=0x6dd5660, com_data=0x7fffec437d80, command=COM_QUERY) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1484
#17 0x00000000015940bc in do_command (thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1025
#18 0x00000000016cbf91 in handle_connection (arg=0x6dda360) at /mysql/mysql-5.7.26/sql/conn_handler/connection_handler_per_thread.cc:306
#19 0x0000000001921c64 in pfs_spawn_thread (arg=0x6d7d0f0) at /mysql/mysql-5.7.26/storage/perfschema/pfs.cc:2190
#20 0x0000003823e079d1 in start_thread () from /lib64/libpthread.so.0
#21 0x0000003823ae8b6d in clone () from /lib64/libc.so.6

```

如果存在重複的行，這需要進行判斷了：

- 如果重複的行正在被其他事務持有，那麼需要進行進行隱試鎖轉換，主鍵的轉換操作如下：
```
->lock_clust_rec_read_check_and_lock
   ->lock_rec_convert_impl_to_expl
      ->lock_rec_convert_impl_to_expl_for_trx
```

因為我們知道通常insert鎖並不會建立顯示的鎖。對於如果出現了重複的行，持有重複行資料的事務並沒有提交或者回滾，需要其事務完成提交或者回滾，然後再進行相應的拋錯或者繼續插入。需要注意的是對於replace/insert on dup 在進行唯一性檢查的時候，通常加的LOCK_S鎖，而其他操作通常加的是 LOCK_X。

- 如果重複的行沒有其他事務持有，那麼丟擲重複行錯誤，但是注意這裡的錯誤不是返回給客戶端的錯誤，是內部錯誤HA_ERR_FOUND_DUPP_KEY，這個錯誤在Innodb層叫做DB_DUPLICATE_KEY（convert_error_code_to_mysql）。如何處理這個錯誤就和相應的語法有關了。

當然如果沒有重複的行，那麼接下來就可以繼續進行insert插入操作了，Insert ignore/replace實現都是進行insert操作。如果有重複行呢？那麼接下來進行分析。

這裡我們也很明白了，對於了insert ignore/replace是透過主鍵/唯一鍵進行判斷是否重複行的，具體點來說就是如何處理錯誤HA_ERR_FOUND_DUPP_KEY。 **如果表中一個能夠判斷唯一性的索引都沒有，那麼即便2條資料一模一樣也不會標記為重複行，視為2條不同的資料**，當然insert on dup 這裡也是同樣的邏輯。
在進行唯一性檢測的時候，會先檢查主鍵的唯一性，然後依次檢查各個唯一索引的唯一性是否滿足。

#####2、可能的回滾操作
首先對於多行插入和insert select來講，每次innodb層插入的行數為1行，我們應該牢牢樹立以行為單位的處理流程，我們可以在函式Sql_cmd_insert::mysql_insert 中找到 一個大的while 迴圈，這就是處理的迴圈。

我們也需要明白，進行判斷唯一性的時候是先判斷主鍵的唯一性，如果滿足則插入主鍵資料，然後依次判斷二級唯一索引，如果滿足則進行插入。這裡涉及到一個問題，如果主鍵資料插入了，但是二級唯一索引由於違法唯一性那麼，前面主鍵插入的資料是需要回滾的。再或者我們執行的insert select操作，其中前面的一些行不違反唯一性插入了，但是隨後的某行違法了唯一性，那麼前面插入的資料也是需要回滾的。函式row_insert_for_mysql_using_ins_graph 中進行這種邏輯處理。

回滾棧幀：

```
#0  row_undo_ins (node=0x73685c0, thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/row/row0uins.cc:466
#1  0x0000000001b5d918 in row_undo (node=0x73685c0, thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/row/row0undo.cc:327
#2  0x0000000001b5dbae in row_undo_step (thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/row/row0undo.cc:411
#3  0x0000000001ab1847 in que_thr_step (thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/que/que0que.cc:1047
#4  0x0000000001ab1a63 in que_run_threads_low (thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/que/que0que.cc:1111
#5  0x0000000001ab1c25 in que_run_threads (thr=0x73671e8) at /mysql/mysql-5.7.26/storage/innobase/que/que0que.cc:1151
#6  0x0000000001bc622b in trx_rollback_to_savepoint_low (trx=0x7fffedc5b8c0, savept=0x7fffec434b60) at /mysql/mysql-5.7.26/storage/innobase/trx/trx0roll.cc:118
#7  0x0000000001bc64d2 in trx_rollback_to_savepoint (trx=0x7fffedc5b8c0, savept=0x7fffec434b60) at /mysql/mysql-5.7.26/storage/innobase/trx/trx0roll.cc:159
#8  0x0000000001b03b92 in row_mysql_handle_errors (new_err=0x7fffec434b5c, trx=0x7fffedc5b8c0, thr=0x7362980, savept=0x7fffec434b60)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:767
#9  0x0000000001b05ff2 in row_insert_for_mysql_using_ins_graph (mysql_rec=0x736e7a0 "\375\n", prebuilt=0x7362170)
    at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1752
#10 0x0000000001b06484 in row_insert_for_mysql (mysql_rec=0x736e7a0 "\375\n", prebuilt=0x7362170) at /mysql/mysql-5.7.26/storage/innobase/row/row0mysql.cc:1859
#11 0x00000000019adca9 in ha_innobase::write_row (this=0x736e4b0, record=0x736e7a0 "\375\n") at /mysql/mysql-5.7.26/storage/innobase/handler/ha_innodb.cc:7598
#12 0x0000000000f67dc0 in handler::ha_write_row (this=0x736e4b0, buf=0x736e7a0 "\375\n") at /mysql/mysql-5.7.26/sql/handler.cc:8062
#13 0x00000000017cf173 in write_record (thd=0x6dd5660, table=0x735afa0, info=0x7fffec435b50, update=0x7fffec435ad0) at /mysql/mysql-5.7.26/sql/sql_insert.cc:1873
#14 0x00000000017cc24a in Sql_cmd_insert::mysql_insert (this=0x6debbc8, thd=0x6dd5660, table_list=0x6deb638) at /mysql/mysql-5.7.26/sql/sql_insert.cc:769
#15 0x00000000017d2d7f in Sql_cmd_insert::execute (this=0x6debbc8, thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_insert.cc:3118
#16 0x000000000159a70c in mysql_execute_command (thd=0x6dd5660, first_level=true) at /mysql/mysql-5.7.26/sql/sql_parse.cc:3596
#17 0x00000000015a06c0 in mysql_parse (thd=0x6dd5660, parser_state=0x7fffec437610) at /mysql/mysql-5.7.26/sql/sql_parse.cc:5570
#18 0x0000000001595283 in dispatch_command (thd=0x6dd5660, com_data=0x7fffec437d80, command=COM_QUERY) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1484
#19 0x00000000015940bc in do_command (thd=0x6dd5660) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1025
#20 0x00000000016cbf91 in handle_connection (arg=0x6dda360) at /mysql/mysql-5.7.26/sql/conn_handler/connection_handler_per_thread.cc:306
#21 0x0000000001921c64 in pfs_spawn_thread (arg=0x6d7d0f0) at /mysql/mysql-5.7.26/storage/perfschema/pfs.cc:2190
#22 0x0000003823e079d1 in start_thread () from /lib64/libpthread.so.0
#23 0x0000003823ae8b6d in clone () from /lib64/libc.so.6

```

######3、對重複錯誤HA_ERR_FOUND_DUPP_KEY 的處理操作

如果有重複的行並且產生了錯誤HA_ERR_FOUND_DUPP_KEY ，那麼就不能進行insert 操作了，這裡就會根據不同的語法進行不同的操作了。我們在函式（write_record ）中可以找到這種分支處理邏輯。

實際上在處理重複行錯誤的時候，在內部分為了3種方式如下：

```
enum enum_duplicates { DUP_ERROR, DUP_REPLACE, DUP_UPDATE };
```
-  DUP_ERROR：這個代表的就是普通的insert/insert ignore語句
這是我們普通的操作，如果是insert操作則進行拋錯給客戶端，如果是insert ignore操作則不進行報錯，僅僅做一個警告，如下：
```
    /*
      If IGNORE option is used, handler errors will be downgraded
      to warnings and don't  have to stop the iteration.
    */

mysql> insert  ignore into tpk2 values(5,'g','m');
Query OK, 0 rows affected, 1 warning (6 min 3.60 sec)

```
但是需要注意的是，當前版本報錯後，自增值並不會回退。

- DUP_REPLACE：這裡代表的是replace操作，也就是使用新的插入資料完全代替違反唯一性約束的行資料。我們通常理解的replace是delete/insert的結合，但是實際上並不完全是這樣，拋開外來鍵觸發器等因素，如果違反的唯一性是最後一個檢查的唯一索引的時候，還是會使用update代替，其他情況下就是delete/insert的結合了。如下我們可以看看：

```
if (last_uniq_key(table,key_nr) &&//是否是檢測的最後一個唯一索引
	    !table->file->referenced_by_foreign_key() &&
            (!table->triggers || !table->triggers->has_delete_triggers()))
        {
          if ((error=table->file->ha_update_row(table->record[1],
					        table->record[0])) && //呼叫了是update介面
              error != HA_ERR_RECORD_IS_THE_SAME) 
          if (error != HA_ERR_RECORD_IS_THE_SAME)
            info->stats.deleted++; //影響行數+1
          goto after_trg_n_copied_inc;
        }
        else
        {
        ...
          if ((error=table->file->ha_delete_row(table->record[1])))//刪除介面 delete
            goto err;
          info->stats.deleted++; //影響行數+1
         ...
          /* Let us attempt do write_row() once more *///這裡會進行一次迴圈進行普通的insert操作
        }
```

- DUP_UPDATE：這個代表我們的語法insert into on dup，這裡就完全等待於update語句了。需要注意的是，這裡不是完全替代，會使用語句中的update進行欄位的更新，其他欄位並不會更新，如下：
```

if ((error=table->file->ha_update_row(table->record[1],
                                                table->record[0])) &&  //調入update介面
              error != HA_ERR_RECORD_IS_THE_SAME)
          {
            
   ...

if (error != HA_ERR_RECORD_IS_THE_SAME)
            info->stats.updated++;//影響行數+1
          else
            error= 0;
```

再說對於普通的insert操作而言，影響的行數通常為1。replace/insert into on dup如果遇到了**重複行更改後**（注意不是直接插入成功的狀態），通常返回影響的行數為2如下：
```
mysql> replace testpri2(id,a,b) values(7,'b','k');
Query OK, 2 rows affected (2.74 sec)

mysql> insert into testpri2(a,b) values('mmmmnb','ffhhh') on DUPLICATE KEY UPDATE b='bj';
Query OK, 2 rows affected (3.81 sec)

```

- replace：如果是呼叫update介面則，不會真正執行insert操作，會在info->stats.deleted++進行影響行數+1，最後在insert介面中還會+1。如果是呼叫delete/insert操作會真正執行insert操作，正常的info->stats.deleted++進行+1操作，最後在insert介面中還會+1。因此它們結果還是2。
- insert into on dup：肯定呼叫update介面，不會真正執行insert操作，會在 info->stats.updated++;進行影響行數+1，然後會直接進行info->stats.copied++進行影響行數+1，因此為2。

因此不管怎麼看起來都是影響行數為2，也不要奇怪。

###其他：

DML回執介面：

```
#0  my_ok (thd=0x6ddc080, affected_rows=1, id=0, message=0x7fffec4357d0 "Rows matched: 1  Changed: 1  Warnings: 0") at /mysql/mysql-5.7.26/sql/sql_class.h:4753
#1  0x0000000001652574 in mysql_update (thd=0x6ddc080, fields=..., values=..., limit=18446744073709551614, handle_duplicates=DUP_ERROR, found_return=0x7fffec435d28, 
    updated_return=0x7fffec435d20) at /mysql/mysql-5.7.26/sql/sql_update.cc:1092
#2  0x00000000016580ea in Sql_cmd_update::try_single_table_update (this=0x6df2350, thd=0x6ddc080, switch_to_multitable=0x7fffec435dcf)
    at /mysql/mysql-5.7.26/sql/sql_update.cc:2891
#3  0x0000000001658637 in Sql_cmd_update::execute (this=0x6df2350, thd=0x6ddc080) at /mysql/mysql-5.7.26/sql/sql_update.cc:3018
#4  0x000000000159a7ba in mysql_execute_command (thd=0x6ddc080, first_level=true) at /mysql/mysql-5.7.26/sql/sql_parse.cc:3606
#5  0x00000000015a06c0 in mysql_parse (thd=0x6ddc080, parser_state=0x7fffec437610) at /mysql/mysql-5.7.26/sql/sql_parse.cc:5570
#6  0x0000000001595283 in dispatch_command (thd=0x6ddc080, com_data=0x7fffec437d80, command=COM_QUERY) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1484
#7  0x00000000015940bc in do_command (thd=0x6ddc080) at /mysql/mysql-5.7.26/sql/sql_parse.cc:1025
#8  0x00000000016cbf91 in handle_connection (arg=0x6dd9480) at /mysql/mysql-5.7.26/sql/conn_handler/connection_handler_per_thread.cc:306
#9  0x0000000001921c64 in pfs_spawn_thread (arg=0x6da4430) at /mysql/mysql-5.7.26/storage/perfschema/pfs.cc:2190
#10 0x0000003823e079d1 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003823ae8b6d in clone () from /lib64/libc.so.6
```

MySQL:pt-online-schema-change原理及注意點（未完）

相關文章