MySQL replace into 語句淺析（二）。本站提示廣大學習愛好者：（MySQL replace into 語句淺析（二））文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL replace into 語句淺析（二）正文
一 引見
上一篇文章引見了replace into的根本道理。本章內容經由過程一個例子解釋 replace into 帶來的潛伏的數據質量風險,當觸及replace into操作的表含有自增主鍵時,主備切換後會形成數據籠罩等紛歧致的情形產生。
二 案例剖析
在主庫上操作
root@test 12:36:51>show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
root@test 12:37:41>insert into t1(name) values('a')
此時檢討主備庫上t1的表構造都是一樣的,AUTO_INCREMENT 都是2.
root@test 12:37:51>show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
在主庫長進行停止replace into操作
root@test 12:37:58>replace into t1(name) values('a');
root@test 12:38:40>replace into t1(name) values('a');
root@test 12:38:49>select * from t1;
+----+------+
| id | name |
+----+------+
| 3 | a |
+----+------+
1 row in set (0.00 sec)
此時檢討主備庫中t1 表構造，請留意AUTO_INCREMENT=4
root@test 12:38:51>show create table t1 \\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
從庫上t1的表構造 ，AUTO_INCREMENT=2
root@test 12:39:35>show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
root@test 12:39:43>select * from t1;
+----+------+
| id | name |
+----+------+
| 3 | a |
+----+------+
1 row in set (0.00 sec)
【剖析】
表t1的表構造 AUTO_INCREMENT=2 而主庫上的t1表構造的AUTO_INCREMENT=4.本來replace操作是在自增主鍵的情形下，碰到獨一鍵抵觸時履行的是delete+insert,然則在記載binlog時,卻記載成了update操作,update操作不會觸及到auto_increment的修正。備庫運用了binlog以後，備庫的表的auto_increment屬性不變。
三 風險點:
假如主備庫產生主從切換，備庫變成本來的主庫，依照本來的營業邏輯再往下會產生甚麼?
root@test 12:40:46>replace into t1(name) values('a');
Query OK, 2 rows affected (0.00 sec)
root@test 12:40:48>select * from t1;
+----+------+
| id | name |
+----+------+
| 2 | a | ---id由本來的3釀成了2.
+----+------+
1 row in set (0.00 sec)
假如t1表原來就存在多筆記錄 ，主從切換以後，運用寫新的主庫則會產生主鍵抵觸，這個留給列位讀者本身測試一下。^_^
四 處理辦法
推舉應用 insert into table values(,....) on duplicate key update 語法構造來處理營業需求。 來防止replace into 給含有自增主鍵的表帶來主從紛歧致情形。
root@test 01:14:28>insert into t1(name) values('a');
Query OK, 1 row affected (0.00 sec)
root@test 01:14:51>insert into t1(name) values('b');
Query OK, 1 row affected (0.00 sec)
root@test 01:14:54>insert into t1(name) values('c');
Query OK, 1 row affected (0.00 sec)
root@test 01:14:57>select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | b |
| 3 | c |
+----+------+
3 rows in set (0.00 sec)
root@test 01:16:17>show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
root@test 01:16:26>insert into tt(name) values('a') on duplicate key update name='a';
Query OK, 1 row affected (0.00 sec)
root@test 01:17:09>show create table t1 \G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
五 總結
因為replace into操作在碰到主鍵抵觸的時刻 會修正主鍵的值,所以假如營業邏輯強依附自增ID,相對不要用replace,通俗情況也不建議如許用,由於replace into 操作能夠會招致主鍵的從新組織.推舉應用 insert into table values(,....) on duplicate key update 來處理營業需求。
