在开发中，可能会碰到这样的场景，往数据库中插入一条记录，如果记录存在的话则更新原纪录。在mysql中，mysql5.0支持了这样的需求，INSERT ... ON DUPLICATE KEY UPDATE语句就是用来处理这样的需求。当插入一条记录时会判断是否存在相同主键的记录。
但这个语句本身存在一些缺陷：
首先他是根据主键进行判断插入更新的， 当mysql执行INSERT ON DUPLICATE KEY的 INSERT时，存储引擎会检查插入的行是否会产生重复键错误。如果是的话，它会将现有的
行返回给mysql，mysql会更新它并将其发送回存储引擎。当表具有多个唯一或主键时，此语句对存储引擎检查密钥的顺序非常敏感。根据这个顺序，存储引擎可以确定不同的行数据给到mysql，因此mysql可以更新不同的行。存储引擎检查key的顺序不是确定性的。例如，InnoDB按照索引添加到表的顺序检查键。
其次，INSERT ... ON DUPLICATE KEY UPDATE语句在高并发的环境下容易产生死锁。insert ... on duplicate key 在执行时，innodb引擎会先判断插入的行是否产生重复key错误，如果存在，在对该现有的行加上S（共享锁）锁，如果返回该行数据给mysql,然后mysql执行完duplicate后的update操作，然后对该记录加上X（排他锁），最后进行update写入。
对于INSERT ON DUPLICATE UPDATE操作，当两个会话S1和S2使用INSERT ON DUPLICATE UPDATE语句操作相同数据且表中存在相同键值记录时，触发死锁场景为：
1. 由于表中已存在重复键值的记录，导致会话先后尝试INSER失败
2. 会话S1进入步骤3尝试获取记录的S锁，该记录未被其他会话加锁，获取S锁成功。
3. 会话S2进入步骤3尝试获取记录的S锁，该记录上被加持S锁，但由于S锁与S锁兼容，获取S锁成功
4. 会话S1进入步骤4尝试获取记录的X锁，由于会话S2对该记录持有S锁，S锁与X锁不兼容，获取X锁失败，会话S1被阻塞
5. 会话S2进入步骤4尝试获取记录的X锁，由于会话S1对该记录持有S锁，S锁与X锁不兼容，获取X锁失败，会话S2被阻塞
6. 会话S2被阻塞后进入死锁检查环节，发现阻塞S1->S2和S2->S1形成死锁环路，触发死锁机制强制回滚S1或S2事务。
PS：尽量不要在有多个唯一键的表使用该语句，也不要在高并发的情况下使用该语句。