在Navicat中为已有表添加唯一索引的正确路径是进入表设计界面→切换至「索引」页签→点击「+」新增索引行→勾选字段→将「索引类型」改为UNIQUE→点击「保存」；该方式比SQL更稳妥，因Navicat自动校验字段类型与NULL约束，但需注意复合索引字段顺序影响查询性能，且NULL值不参与唯一性校验。
在Navicat中给已有表加唯一索引的正确路径
直接在表设计界面点「索引」页签添加，比用SQL语句更稳妥——Navicat会自动校验字段类型和NULL约束，避免因手动写错 UNIQUE 语法或忽略 NOT NULL 导致索引失效。
操作时注意：必须先选中要参与索引的字段（可多选），再点击左下角「+」号新增索引行，最后把「索引类型」下拉框从默认的 INDEX 改为 UNIQUE。改完不点「保存」，索引不会真正创建。
- 如果字段允许
NULL，MySQL 仍会接受多条NULL值记录（符合 SQL 标准），但这常被误认为“唯一性没生效” - 复合唯一索引字段顺序影响查询性能，高频
WHERE条件字段建议放前面 - Navicat 15+ 版本对 JSON、Generated Column 类型支持有限，这类字段加唯一索引会报错
ERROR 3106
执行前必须检查的三类冲突数据
Navicat 创建唯一索引时若检测到重复值，会直接中断并提示 Cannot add or update a child row: a foreign key constraint fails 或更常见的 Duplicate entry 'xxx' for key 'xxx'——但它不会告诉你具体哪几行冲突。
得自己先查：
SELECT column_name, COUNT(*) FROM table_name GROUP BY column_name HAVING COUNT(*) > 1;
- 对复合索引，
GROUP BY要写全字段，例如GROUP BY email, status - 有空格或大小写差异？用
TRIM()和BINARY精确比对：SELECT BINARY email, COUNT(*) FROM users GROUP BY BINARY email HAVING COUNT(*) > 1 - 时间字段含微秒？
DATETIME(6)可能因精度导致看似重复实则不同，需统一截断到秒级再查
用SQL手动建唯一索引的两种安全写法
图形界面卡顿、字段名含特殊字符（如连字符）、或需要指定索引名时，推荐用「运行SQL文件」或「查询窗口」执行语句。但别直接写 CREATE UNIQUE INDEX ——它遇到重复会失败且不回滚。
- 先建普通索引快速验证字段组合是否真无重复：
CREATE INDEX idx_temp ON table_name (col_a, col_b);，成功后再删掉重来 - 真正建唯一索引时，用
ALTER TABLE更可控：ALTER TABLE users ADD CONSTRAINT uk_email UNIQUE (email);，约束名uk_email方便后续定位和删除 - 如果表很大（千万级），加索引会锁表。生产环境务必在低峰期操作，并提前加
ALGORITHM=INPLACE（MySQL 5.6+）减少锁时间：ALTER TABLE users ADD UNIQUE (email) ALGORITHM=INPLACE;
唯一索引生效后仍插入重复的典型原因
不是索引没建成功，而是业务逻辑绕过了约束。最常见三种情况：
-
INSERT IGNORE或ON DUPLICATE KEY UPDATE语句会静默吞掉重复错误，日志里看不到报错，但数据没进表 - 应用层做了“先查后插”，两个并发请求同时查到“不存在”，然后都插入——这是典型的竞态条件，唯一索引能拦住，但代码得配合重试或事务
- 字段用了前缀索引，比如
ADD UNIQUE (title(100))，那超过100字符的长文本前100位相同就会被判定重复，实际内容却不同
真正难排查的是第三种：前缀长度设太短，既浪费空间又起不到去重作用。建索引前用 SELECT COUNT(DISTINCT LEFT(title, 100)) / COUNT(*) FROM articles; 算下选择性，低于 0.9 就该加长。
