绝大多数等值查询下唯一索引和普通索引性能几乎无差别，核心区别在于唯一索引由数据库强制校验重复值以保障数据一致性，而普通索引仅加速查询且允许重复插入。

唯一索引和普通索引，查得一样快，但语义完全不同

直接说结论：**绝大多数等值查询（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、email、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 缓存写），直接命中页就判断并拒绝
• 真正拖慢写入的，往往是索引太多、字段太长、或没走索引导致全表扫描校验（比如在没索引的列上加唯一约束）

所以别为了“怕慢”放弃唯一性保障；先确保字段上有对应索引，再谈优化。