MySQL中处理唯一键冲突：使用错误码1062

说实话，MySQL这玩意儿挺有意思的。
你要是给某个字段加了UNIQUE约束，那它就非得让你填个不一样的值。
你非要填一样的，比如注册时邮箱重复，MySQL立马就给你返回个错误，错误码是1 06 2 这个码是个固定码，比看那个错误信息字符串强多了，因为中文环境里字符串可能乱码。

我之前做项目时也踩过坑。
用PHP连MySQL，最早用的是mysqli扩展。
建连接那部分代码是这么写的： php $conn = new mysqli('localhost', 'username', 'password', 'database'); if ($conn->connect_error) { die("Connection failed: " . $conn->connect_error); }
连接没问题后，关键来了。
直接拼接字符串写SQL很危险，我以前也这么干过，现在想想太蠢了。
比如： php $sql = "INSERT INTO table (entry) VALUES('" . $entry_value . "')";
这写法现在想想都后怕，SQL注入随时可能来搞你。

现在都该用预处理语句了。
代码是这样： php $stmt = $conn->prepare("INSERT INTO table (entry) VALUES(?)"); $stmt->bind_param("s", $entry_value); $stmt->execute();
这里问号是占位符，后面bind_param把值传过去。
这样既安全，也清晰。

执行完之后，你就得看errno。
如果是1 06 2 ，那就是唯一键冲突了。
处理方式得友好点，别直接把数据库的错误信息怼给用户。
比如： php if ($stmt->errno == 1 06 2 ) { echo "Error: Duplicate entry detected. Please try another value."; } else { error_log("Database error: " . $stmt->error); echo "An unexpected error occurred. Please try again later."; }
把数据库的错误先记日志里，别直接给用户看。
用户就看到你写的友好提示。

PDO扩展也类似，不过它用SQLSTATE码。
如果执行后用errorCode()返回的是2 3 000，那就是唯一键冲突。
代码这样写： php $stmt = $pdo->prepare("INSERT INTO table (entry) VALUES(:value)"); $stmt->execute([':value' => $entry_value]); if ($stmt->errorCode() == '2 3 000') { echo "Duplicate entry error."; }
跨数据库兼容性这事儿，得特别注意。
MySQL用1 06 2 ，PostgreSQL用2 3 5 05 ，Oracle可能又不一样。
你要是写个通用的系统，就得抽象这一层，根据数据库类型判断错误码。

完整代码我之前也写过一个，mysqli+预处理语句的版本： php $servername = "localhost"; $username = "username"; $password = "password"; $dbname = "database"; $conn = new mysqli($servername, $username, $password, $dbname); if ($conn->connect_error) { die("Connection failed: " . $conn->connect_error); } $entry_value = "some_unique_value"; $stmt = $conn->prepare("INSERT INTO table (entry) VALUES(?)"); $stmt->bind_param("s", $entry_value); if ($stmt->execute()) { echo "New record created successfully"; } else { if ($stmt->errno == 1 06 2 ) { echo "Error: The value already exists. Please choose another one."; } else { error_log("Database error: " . $stmt->error); echo "An error occurred. Please contact support."; } } $stmt->close(); $conn->close();
这代码现在看还挺清晰的。

总的来说，检查1 06 2 这错误码就够你应对大多数唯一键冲突的场景了。
加上预处理语句和完善的错误处理，代码看着就舒服多了。
实际用的时候，根据自己业务需求再扩展点功能，比如自动重试或者数据回滚啥的。

mysql主键和唯一键区别？如何选择主键？

哎呦，说到MySQL的主键和唯一键，这俩家伙啊，可真是有区别的。
先说约束条件吧，主键那可是必须得唯一，还不能有空值，就相当于每个表里的一条记录都有它独一无二的身份证号。
而唯一键呢，虽然它也要求字段值不能重复，但允许空值，就像有些人可能没填邮箱，但这邮箱地址要是填了，就得是独一无二的。

再来说说数量限制，主键呢，一个表就一个，不管是单列还是多列。
唯一键呢，一个表可以有好几个，你想在哪个字段上保证唯一，就设哪个字段为唯一键。

然后是索引类型，主键自动就给你弄了个聚集索引，数据按照主键的顺序来存储，查询效率那是杠杠的。
唯一键呢，默认是非聚集索引，查询的时候得先查索引，然后再回表找数据，效率稍微差点。

选主键的时候啊，得先考虑稳定性，别的主键改了，这个表里的所有外键都得跟着改，头疼得很。
还得考虑简洁高效，自增的整数是最好的选择，简单，效率高。
还有啊，别用那些业务字段，比如身份证号、手机号，它们可能会变，或者格式复杂。

唯一键呢，适用场景就多了，比如用户名、邮箱这些，虽然不是唯一标识，但得保证它们不重复。
复合唯一键也很实用，比如订单明细表，得保证同一个订单里不能重复添加同一个商品。

主键查询那是快的，直接定位数据页，不用回表。
唯一键查询得先查索引，再回表，效率低一点。
但优化一下，比如把常用作查询的唯一键设为主键，也能提高效率。

总之啊，设计数据库结构的时候，得好好考虑主键和唯一键，保证数据一致性和查询性能。

mysql中的键是什么意思

我记得有一次，我在一家小型的电商公司工作，那时候我们公司正在开发一个新系统。
有一次，我在数据库设计阶段，遇到了一个难题：如何为订单表设计合适的键。

订单表需要记录用户购买商品的信息，而每个订单都有唯一的订单号，所以我决定将订单号设为主键。
但是，订单表里还需要记录用户信息和商品信息，这就涉及到如何设计复合键。

当时，我查阅了很多资料，发现复合键可以由多个列组成，组合值必须唯一。
于是，我决定将用户ID和商品ID组合成复合键，这样可以确保每个订单都对应一个唯一的用户和一个唯一的商品。

在实际操作中，我发现通过复合键查询订单信息时，效率确实比单列索引要高很多。
而且，由于订单表和用户表、商品表之间有关联，我还在订单表中添加了外键，以维护表间关系和数据一致性。

这个经历让我深刻体会到，选择合适的键类型对于数据库性能和完整性至关重要。
但是，我也意识到，过度索引会降低写入性能，所以在设计数据库时，需要权衡利弊，合理使用键。
等等，我突然想到，如果以后遇到类似的问题，是不是还可以考虑使用唯一键来优化某些字段的查询效率呢？

mysql 唯一键可以为 null

上周有个客人问我关于MySQL唯一键和NULL值的问题，我就给他详细解释了一下。
首先，MySQL默认情况下，唯一键是不能为NULL的，因为唯一键的定义就是要保证每一列或者列组合的唯一性，而NULL代表的是未知或者不存在，它不具备确定性，所以两行数据的唯一键列都是NULL时，数据库无法判断它们是否重复。

我举个例子，如果有一个表叫users，里面有一个username列，它是VARCHAR类型并且设置为UNIQUE，那么当你尝试插入两个NULL值到username列时，第一个可以成功插入，第二个就会因为违反唯一性约束而失败。

但是，如果唯一键是由多列组成的，比如(username, user_type)，并且其中一列允许NULL，那么不同行的NULL值与其他列的组合是可以是唯一的。
比如，我创建了一个表，其中username和user_type是唯一键，我可以插入两个NULL的username，但是user_type不同，这样就不会违反唯一性约束。

对于处理NULL值，我建议可以采用组合唯一键、设置默认值或者使用MySQL 8 .0以上的部分索引。
比如，你可以给列设置一个默认值，比如空字符串或者特定标记值，这样就可以直接使用唯一键约束。
或者，如果你需要区分NULL的不同场景，你可以创建一个组合唯一键。

性能方面，唯一键的开销是每次插入或更新数据时，数据库都需要检查唯一性约束，这可能会在高并发场景下影响性能。
因此，选择合适的索引类型，比如B-tree索引，可以优化检查效率。
同时，定期监控数据库性能指标，根据实际负载调整索引设计，也是很重要的。

反正，设计数据库的时候，要根据业务需求和性能要求来选择合适的方案。
我还在想这个问题，可能还有其他的方法或者优化点，不过这些基本的思路应该没问题。