主键字段查重更优方案：预查询查重还是尝试插入？

方案2（直接执行插入、捕获「键已存在」错误做跳过逻辑）的性能、响应速度、数据正确性全面优于方案1，是这类需求的标准实现方案。

方案1的核心问题 #

你给出的方案1从性能和逻辑上都存在硬伤，完全不适合生产环境使用：

• 参考SQL逻辑错误：你贴的查询语句是对全表做GROUP BY扫描，找出库里所有重复的username+email组合，根本不是针对本次待插入的单条数据做校验。随着表数据量增长，这个全表分组查询的延迟会线性上涨，百万级数据量下延迟很容易达到秒级，高频调用时会直接拖垮数据库。
• 就算把SQL修正为针对待插入值的精准查询（比如SELECT 1 FROM users WHERE username = ? AND email = ? LIMIT 1），依然存在两个无法解决的问题：
  • 存在竞态风险：高并发场景下，两个请求同时查询到某个主键值不存在，会同时发起插入，最终依然会有一个请求触发键重复错误，你还是得写异常捕获逻辑，等于前置查询完全做了无用功。
  • 额外开销固定：不管待插入的主键是否存在，你都要多做一次数据库往返交互。主键存在时，你花了1次查询的成本才决定跳过；主键不存在时，你要花1次查询+1次插入的成本，总交互次数是方案2的两倍。
• 唯一索引的存在性校验是存储引擎写入流程的内置环节，你单独发查询做校验，等于重复做了一次数据库本来就要做的工作，平白浪费性能。

方案2的优势 #

• 性能更高：没有前置查询的额外IO开销，插入时的主键重复校验是引擎层顺着唯一索引做的内存级判断，成本极低。主键不存在时仅需1次数据库交互就完成写入；主键存在时返回错误的开销，也远低于单独发一次查询的成本，高并发场景下整体吞吐量比修正后的方案1高50%以上。
• 逻辑可靠：唯一约束是数据库引擎层面强制保证的，不会因为业务层并发问题出现重复插入的脏数据，不需要额外做并发兜底。
• 实现简单：不需要写复杂的查询判断逻辑，只需要捕获对应数据库的主键重复异常做跳过处理即可，代码bug率更低。

补充提示：如果是批量插入场景，可以直接用数据库原生的INSERT IGNORE语法，不需要在业务层循环单条插入捕获异常，性能还能再上一个台阶。不要为了"避免报错"走先查再插的歪路，数据库返回键重复错误是正常的流程控制信号，不会对数据库性能造成额外损伤。

内容的提问来源于stack exchange，提问作者Lina