应用程序开发中有个较常见的场景, 查询某字段的值(该字段一般具有唯一性), 是否存在, 若不存在, 则插入一条记录, 反之, 就更新该记录.
常见的方法是, SELECT... FROM ... FOR UPDATE查询下, 根据SELECT返回情况, 进行相应的操作. 实践中发现, 并发量较大时, 可能会有较多死锁的情况发生,下面利用tb1表演示该问题.
tb1的表结构为:
mysql>SHOW CREATE TABLE tb1 \G
***************************1. row ***************************
Table: tb1
CreateTable: CREATE TABLE `tb1` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`category` varchar(20) NOT NULL DEFAULT ‘‘,
`quantity` bigint(20) NOT NULL DEFAULT ‘0‘,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_category` (`category`)
)ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4
1 rowin set (0.00 sec)
Session1:
mysql>BEGIN;
QueryOK, 0 rows affected (0.00 sec)
mysql>SELECT * FROM tb1 WHERE category = ‘ko_007‘ FOR UPDATE;
Emptyset (0.00 sec)
Session2:
mysql>BEGIN;
QueryOK, 0 rows affected (0.00 sec)
mysql>SELECT * FROM tb1 WHERE category = ‘ko_007‘ FOR UPDATE;
Emptyset (0.00 sec)
Session1插入category为‘ko_007‘的记录, 出现了锁等待.
mysql>INSERT INTO tb1 (category) VALUES (‘ko_007‘);
…
Session2也插入category为‘ko_007‘的记录, 死锁的情况发生了.
mysql>INSERT INTO tb1 (category) VALUES (‘ko_007‘);
ERROR1213 (40001): Deadlock found when trying to get lock; try restartingtransaction
针对死锁的产生, 从数据库本身来看, 是否还有其它方法完成上面的需求呢 …
MySQL提供了INSERT ... ON DUPLICATE KEY UPDATE语法, 其运行方式是: 若主键(或唯一键)不存在, 就插入一条记录; 若主键存在, 则更新该记录.
对于上述需求, 单个SQL语句即可搞定: 有则更新, 无则插入.
INSERTINTO tb1 (category) VALUES (‘ko_007‘) ON DUPLICATE KEY UPDATE quantity =quantity + 1;
近日, 项目的一个分布式日志产生量统计程序, 从Kafka订阅消息处理后, 将结果写入数据库, 就使用了INSERT ... ON DUPLICATE KEY UPDATE. 其虽不像SELECT ... FROM ... FOR UPDATE容易发生死锁, 却发现了另外一个问题: 与数据表主键相关的AUTO_INCREMENT值非常大, 主键值呈跳跃式增长, 这样持续下去, 主键值要不够用了啊!
最初想到的可能是, innodb_autoinc_lock_mode设置为2引起的, 确认后, 其值是1. 哎, 原因还未找到.
测试下INSERT... ON DUPLICATE KEY UPDATE, 过程如下面所示:
tb1表中存在category 为‘ko_007‘的记录:
mysql>SELECT * FROM tb1 WHERE category = ‘ko_007‘;
+----+----------+----------+
| id| category | quantity |
+----+----------+----------+
| 10| ko_007 | 1 |
+----+----------+----------+
1 rowin set (0.00 sec)
此时查看表结构, AUTO_INCREMENT为12:
mysql>SHOW CREATE TABLE tb1 \G
***************************1. row ***************************
Table: tb1
CreateTable: CREATE TABLE `tb1` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`category` varchar(20) NOT NULL DEFAULT ‘‘,
`quantity` bigint(20) NOT NULL DEFAULT ‘0‘,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_category` (`category`)
)ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4
1 rowin set (0.00 sec)
执行下面的SQL:
mysql>INSERT INTO tb1 (category) VALUES (‘ko_007‘) ON DUPLICATE KEY UPDATE quantity =quantity + 1;
QueryOK, 2 rows affected (0.00 sec)
查看category 为‘ko_007‘的记录, 和表结构, 可看到quantity 字段更新为2, AUTO_INCREMENT增加了1, 变为13, 如下面所示:
mysql>SELECT * FROM tb1 WHERE category = ‘ko_007‘;
+----+----------+----------+
| id| category | quantity |
+----+----------+----------+
| 10| ko_007 | 2 |
+----+----------+----------+
1 rowin set (0.00 sec)
mysql>SHOW CREATE TABLE tb1 \G
***************************1. row ***************************
Table: tb1
CreateTable: CREATE TABLE `tb1` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`category` varchar(20) NOT NULL DEFAULT ‘‘,
`quantity` bigint(20) NOT NULL DEFAULT ‘0‘,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_category` (`category`)
)ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4
1 rowin set (0.00 sec)
其实查看MySQL官方文档对于INSERT ... ON DUPLICATE KEY UPDATE的说明时，细心的话可发现文档早已说明了该语法UPDATE唯一记录时, AUTO_INCREMENT会增加的.
大致的原因是, MySQL在执行INSERT ... ON DUPLICATE KEY UPDATE时, 首先要AUTO_INCREMENT+1获取可用的自增值, 继续后面的逻辑时, MySQL发现这是个UPDATE操作, 继而更新相应的记录.
既然整数型的自增主键值有用完的风险, 那使用VARCHAR数据类型的字段作为主键, 就避开该问题呀, 确实是, 调整后的表结构如下:
mysql>SHOW CREATE TABLE tb2 \G
***************************1. row ***************************
Table: tb2
CreateTable: CREATE TABLE `tb2` (
`category` varchar(20) NOT NULL DEFAULT ‘‘,
`quantity` bigint(20) NOT NULL DEFAULT ‘0‘,
PRIMARY KEY (`category`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
1 rowin set (0.00 sec)
但这也可能带来某些副作用,如数据表存储空间变大, 主从复制效率降低等等…