java duplicate entry_java向数据库插入数据时的错误： Duplicate entry '' for key 'PRIMARY' 问题解决...

错误提示为：你插入的记录与数据表中原有记录的主键重复了(Duplicate)。所以插入失败

mysql主键设置成auto_increment时，进行并发性能测试出现主键反复Duplicate entry 'xxx' for key 'PRIMARY'

解决方法：

在my.cnf的[mysqld]片段中加入设置innodb_autoinc_lock_mode=0

同一时候注意调大jdbc的活跃链接数，如设置 jdbc.maxActive=300，由于设置innodb_autoinc_lock_mode=0可能导致链接过多。

注意，这样的方式仅仅须要在并发性能测试时设置，由于这样的方式在插入记录时需进行全表锁定，性能较差，平时生产环境中仅仅需使用默认的设置innodb_autoinc_lock_mode=1就可以，mysql的官方文档有说明：

1、innodb_autoinc_lock_mode = 0 (“traditional” lock mode)

这样的方式就和mysql5.1.22曾经一样，这样的方式的特点就是“表级锁定”，并发性较差

2、innodb_autoinc_lock_mode = 1 (“consecutive” lock mode)

这样的方式是新版本号中的默认方式，推荐使用，并发性相对较高，特点是“consecutive”，即保证同一条insert语句中新插入的auto_increment id都是连续的。

这样的模式下：

“Simple inserts”：直接通过分析语句，获得要插入的数量，然后一次性分配足够的auto_increment id，仅仅会将整个分配的过程锁住。

“Bulk inserts”：由于不能确定插入的数量，因此使用和曾经的模式同样的表级锁定。

“Mixed-mode inserts”：直接分析语句，获得最坏情况下须要插入的数量，然后一次性分配足够的auto_increment id，仅仅会将整个分配的过程锁住。须要注意的是，这样的方式下，会分配过多的id，而导致”浪费“。比方INSERT INTO t1 (c1,c2) VALUES (1,’a'), (NULL,’b'), (5,’c'), (NULL,’d');会一次性的分配5个id，而无论用户是否指定了部分id；INSERT … ON DUPLICATE KEY UPDATE一次性分配，而无论将来插入过程中是否会由于duplicate key而只运行update操作。

注意：当master mysql版本号<5.1.22，slave mysql版本号>=5.1.22时，slave须要将innodb_autoinc_lock_mode设置为0，由于默认的 innodb_autoinc_lock_mode为1，对于INSERT … ON DUPLICATE KEY UPDATE和INSERT INTO t1 (c1,c2) VALUES (1,’a'), (NULL,’b'), (5,’c'), (NULL,’d');的运行结果不同，现实环境通常会使用INSERT … ON DUPLICATE KEY UPDATE。

3、innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)

这样的模式是来一个分配一个，而不会锁表，仅仅会锁住分配id的过程，和innodb_autoinc_lock_mode = 1的差别在于，不会预分配多个，这样的方式并发性最高。可是在replication中当binlog_format为statement-based时 (简称SBR statement-based replication)存在问题，由于是来一个分配一个，这样当并发运行时，“Bulk inserts”在分配的时会同一时候向其它的INSERT分配，会出现主从不一致(从库运行结果和主库运行结果不一样)，由于binlog仅仅会记录开始的 insert id。