唯一索引和普通索引，查得一样快，但语义完全不同
直接说结论：**绝大多数等值查询（
WHERE column = ?）下，唯一索引和普通索引的性能几乎没差别**。B+树定位到数据页后，InnoDB 都是把整页读进内存再二分查找；唯一索引多做的只是「找到第一个就停」，普通索引要多判断一次下一行是否还匹配——这个开销在 16KB 数据页里基本可忽略。
但关键不在快不快，而在「数据库是否帮你拦住脏数据」：
普通索引INDEX：只加速查询，允许重复值插入，哪怕你重复插 100 次手机号
'13800138000'，MySQL 也照收不误 唯一索引
UNIQUE：一旦定义，MySQL 会在
INSERT或
UPDATE时自动校验——发现重复就报错
ERROR 1062 (23000): Duplicate entry 'xxx' for key 'idx_phone'注意：
UNIQUE允许
NULL，且多个
NULL不算重复（这是 SQL 标准行为）
什么时候必须用唯一索引？不是“想快一点”，而是“不能错”
典型场景就是业务上天然要求字段全局唯一，且你不想靠应用层反复查库再插入（容易并发冲突）：
用户表的id_card、
username订单表的
out_trade_no（外部交易号） 设备表的
sn（序列号） 防重场景：比如限制同一用户每天只能提交一条反馈，可建联合唯一索引
UNIQUE(user_id, DATE(created_at))
别图省事只加普通索引再靠代码 try-catch 插入失败——这会把数据一致性压力全推给应用，且并发下极易漏判。
建索引时写错关键字，后果很隐蔽
常见错误不是语法报错，而是「你以为建了唯一索引，其实建成了普通索引」：
错：用CREATE INDEX idx_email ON users(email);→ 普通索引，无唯一约束 对：用
CREATE UNIQUE INDEX idx_email ON users(email);→ 真正生效的唯一索引 更隐蔽的错：已有普通索引，又执行
ALTER TABLE users ADD UNIQUE(email);→ 这条语句会失败（如果已有重复值），但很多人没检查返回值，误以为成功 验证是否真建成了唯一索引：
SHOW INDEX FROM users WHERE Key_name = 'idx_email';看
Non_unique列：0 = 唯一索引，1 = 普通索引
唯一索引会影响 INSERT/UPDATE 性能？要看场景
唯一索引确实需要额外做「是否存在」校验，但实际影响有限：
如果该值大概率不存在（如新用户注册填新邮箱），校验成本≈一次主键查询，通常0.1ms级别 如果该值大概率已存在（如高频重试插入同一订单号），唯一索引反而更快——它不用走 change buffer（普通索引在非聚集页更新时依赖 change buffer 缓存写），直接命中页就判断并拒绝 真正拖慢写入的，往往是索引太多、字段太长、或没走索引导致全表扫描校验（比如在没索引的列上加唯一约束）
所以别为了“怕慢”放弃唯一性保障；先确保字段上有对应索引，再谈优化。
