唯一索引本质是数据完整性约束而非性能优化手段，其应用前提为字段在业务上天然不可重复（如order_no、email），且须预先清理重复数据、审慎处理NULL及高并发写入锁竞争。
字段值是否天然具备业务唯一性
唯一索引不是性能优化手段，而是数据完整性约束。判断起点永远是业务逻辑：这个字段在现实世界中是否「本就不该重复」？比如 order_no、email、sku_code 这类字段，重复即意味着数据错误或资损，必须加唯一索引。反过来，像 nickname、remark、status 这类字段，即使查重也属于业务校验范畴，不该依赖唯一索引兜底。
已有数据是否存在重复值
加唯一索引前不检查重复，100%会失败。执行以下语句确认：
SELECT phone, COUNT(*) FROM users GROUP BY phone HAVING COUNT(*) > 1;
如果返回结果非空，说明存在脏数据。此时不能跳过清理直接建索引——MySQL 会报错 ERROR 1062 (23000): Duplicate entry 'xxx' for key 'uk_phone'。处理方式只有三种：
- 清理重复记录（推荐，尤其对用户/订单等核心表）
- 用
ALTER IGNORE TABLE ... ADD UNIQUE INDEX（MySQL 5.7 及以前可用，8.0+ 已移除，不建议依赖） - 先建普通索引 + 应用层强校验 + 后续逐步修复（仅限灰度或临时方案）
字段是否允许 NULL 且业务上需区分多个 NULL
MySQL 的唯一索引允许同一列存在多个 NULL 值，因为 NULL != NULL。这和很多开发直觉相悖。例如：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
INSERT INTO users (email) VALUES (NULL), (NULL), ('a@b.com');
这条语句能成功执行，不会触发唯一冲突。但如果你的业务要求「未填写邮箱」必须唯一（比如一个用户只能有一条“待补全邮箱”记录），那单靠唯一索引无法满足，得配合 NOT NULL 或应用层控制。
写入压力是否可承受索引维护开销
每次 INSERT / UPDATE 唯一索引字段时，MySQL 都要先查一遍索引树确认无冲突，再写入数据页。对高频写入场景（如日志表、实时埋点表），这个额外检查可能成为瓶颈。典型信号包括：
- 慢查询日志中频繁出现
Duplicate entry报错（说明应用层没做好预判，反复试错插入） -
innodb_row_lock_waits指标突增（唯一索引冲突会加锁） - 批量导入时速度断崖式下降
这时候得权衡：是接受少量重复由应用兜底去重，还是接受写入变慢换数据绝对正确。没有标准答案，但金融、订单类系统通常选后者。
真正容易被忽略的是 NULL 行为和写入锁竞争这两点。很多人只记得“加了唯一索引就不会重复”，却没意识到 MySQL 对 NULL 的宽松处理可能掩盖逻辑漏洞，也没想到高并发插入时唯一性检查本身就会变成锁热点。
