# Percona mysql 8.0.21 unique key column but still insert duplicate data **URL:** \ **Category:** Percona Server for MySQL\ **Tags:** mysql, bugs\ **Created:** [October 17, 2023, 6:09am UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959 "2023-10-17T06:09:45Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![anly\_zhang](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anly_zhang/32/13350_2.png) [@anly\_zhang](https://forums.percona.com/u/anly_zhang)\ **Post date:** [October 17, 2023, 6:09am UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959/1 "2023-10-17T06:09:45Z")
**version 8.0.21** **transaction\_isolation=READ-COMMITTED** table create statement ```auto CREATE TABLE `t_level_log` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'PK', `log_id` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL , `login_name` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL , `level_change_before` tinyint NOT NULL COMMENT 'level before', `level_change_after` tinyint NOT NULL COMMENT 'level after', `level_integral` bigint NOT NULL , `reviced_time` datetime DEFAULT NULL , `create_time` datetime NOT NULL , `creator` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL , `update_time` datetime DEFAULT NULL , `updater` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL , `approval_time` datetime DEFAULT NULL , `approval_by` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL , `integral_order_id` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL , PRIMARY KEY (`id` ), UNIQUE KEY `uk_ll_li` (`log_id` ), ) ENGINE=InnoDB AUTO_INCREMENT=127810 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ``` already had data ```auto select * from t_level_log where log_id='LLL25635165'; +--------+-------------+-----------------+---------------------+--------------------+----------------+--------------+---------------------+---------+---------------------+---------+---------------------+-------------+---------------------+ | id | log_id | login_name | level_change_before | level_change_after | level_integral | reviced_time | create_time | creator | update_time | updater | approval_time | approval_by | integral_order_id | +--------+-------------+-----------------+---------------------+--------------------+----------------+--------------+---------------------+---------+---------------------+---------+---------------------+-------------+---------------------+ | 118806 | LLL25635165 | 0ix4pk | 0 | 1 | 10 | NULL | 2023-10-11 19:30:26 | SYSTEM | 2023-10-11 19:30:26 | SYSTEM | 2023-10-11 19:30:26 | SYSTEM | 1712068130404188160 | +--------+-------------+-----------------+---------------------+--------------------+----------------+--------------+---------------------+---------+---------------------+---------+---------------------+-------------+---------------------+ 1 row in set (0.01 sec) ``` an new data insert sucessfull. ```auto # at 7934293 #231017 5:42:05 server id 642064311 end_log_pos 7934698 Rows_query # INSERT INTO t_level_log ( log_id, # login_name, # integral_order_id, # level_change_before, # level_change_after, # level_integral, # create_time, # creator, # update_time, # updater, # approval_time, # approval_by ) VALUES ( 'LLL25635165', # '0k4edt', # '1714034000538021888', # 0, # 1, # 10, # '2023-10-17 05:42:05.656', # 'SYSTEM', # '2023-10-17 05:42:05.656', # 'SYSTEM', # '2023-10-17 05:42:05.656', # 'SYSTEM' ) # at 7934698 #231017 5:42:05 server id 642064311 end_log_pos 7934792 Table_map: c66_integral.t_level_log mapped to number 165 # at 7934792 #231017 5:42:05 server id 642064311 end_log_pos 7934930 Write_rows: table id 165 flags: STMT_END_F ### INSERT INTO c66_integral.t_level_log ### SET ### @1=127788 /* LONGINT meta=0 nullable=0 is_null=0 */ ### @2='LLL25635165' /* VARSTRING(256) meta=256 nullable=0 is_null=0 */ ### @3='0k4edt' /* VARSTRING(80) meta=80 nullable=0 is_null=0 */ ### @4=0 /* TINYINT meta=0 nullable=0 is_null=0 */ ### @5=1 /* TINYINT meta=0 nullable=0 is_null=0 */ ### @6=10 /* LONGINT meta=0 nullable=0 is_null=0 */ ### @7=NULL /* DATETIME(0) meta=0 nullable=1 is_null=1 */ ### @8='2023-10-17 05:42:06' /* DATETIME(0) meta=0 nullable=0 is_null=0 */ ### @9='SYSTEM' /* VARSTRING(128) meta=128 nullable=1 is_null=0 */ ### @10='2023-10-17 05:42:06' /* DATETIME(0) meta=0 nullable=1 is_null=0 */ ### @11='SYSTEM' /* VARSTRING(128) meta=128 nullable=1 is_null=0 */ ### @12='2023-10-17 05:42:06' /* DATETIME(0) meta=0 nullable=1 is_null=0 */ ### @13='SYSTEM' /* VARSTRING(128) meta=128 nullable=1 is_null=0 */ ### @14='1714034000538021888' /* VARSTRING(256) meta=256 nullable=1 is_null=0 */ ``` can anyone give me some help ? ---
**Author:** ![yunus.uyanik](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus.uyanik/32/19250_2.png) [@yunus.uyanik](https://forums.percona.com/u/yunus.uyanik)\ **Post date:** [October 17, 2023, 11:21am UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959/2 "2023-10-17T11:21:31Z")
Hi anly\_zhang, I couldn’t reproduce it with the same version. Can you show a little demonstration? Do you have two records now and are you using some triggers? ---
**Author:** ![anly\_zhang](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anly_zhang/32/13350_2.png) [@anly\_zhang](https://forums.percona.com/u/anly_zhang)\ **Post date:** [October 17, 2023, 12:05pm UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959/3 "2023-10-17T12:05:39Z")
I can’t reproduce this problem either, but there is such a situation in the production database. But it was found that the data was indeed written. as shown below： ![telegram-cloud-photo-size-5-6156977847114250263-y](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/1/1d9ea768e83b836c5452a99545991fc557e67c7b.jpeg) I tried the following but couldn’t reproduce it: 1. Parse the SQL from the binlog and re-execute it, but the data cannot be written. 2. First write a different data, and then update the log\_id to existing one, and it will also prompt rejection. ---
**Author:** ![anly\_zhang](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anly_zhang/32/13350_2.png) [@anly\_zhang](https://forums.percona.com/u/anly_zhang)\ **Post date:** [October 17, 2023, 12:06pm UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959/4 "2023-10-17T12:06:12Z")
In addition, if you use equivalent query, you can only find one of the data ![telegram-cloud-photo-size-5-6156977847114250265-y](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/9/9dc7afb19a53c7e0c6446f16fb797c95d6341e62.jpeg) ---
**Author:** ![anly\_zhang](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anly_zhang/32/13350_2.png) [@anly\_zhang](https://forums.percona.com/u/anly_zhang)\ **Post date:** [October 17, 2023, 12:06pm UTC](https://forums.percona.com/t/percona-mysql-8-0-21-unique-key-column-but-still-insert-duplicate-data/25959/5 "2023-10-17T12:06:49Z")
Trying to use md5 to verify whether the data is the same, the result shows that the data is the same, I can’t find the reason. ![telegram-cloud-photo-size-5-6156977847114250264-y](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/0/0879fed85813a21bf367bc44745d253f8057135c.jpeg)