唯一索引和普通索引的核心区别在于是否强制字段值唯一：唯一索引禁止重复值并自带约束校验，普通索引仅加速查询且不限制重复；二者查询性能相近，但优化器对唯一索引可做更优执行计划；适用场景不同，唯一索引用于天然唯一字段（如手机号、订单号），普通索引用于允许重复的高频查询字段（如状态、用户ID）。
唯一索引和普通索引的核心区别在于是否强制字段值的唯一性：唯一索引要求索引列（或组合列）的值不能重复，插入或更新时若违反将报错；普通索引只加速查询，不限制数据重复。
约束能力不同：唯一索引自带业务规则校验
唯一索引在物理层面同时承担约束（Constraint）和索引（Index）双重角色。数据库会自动拒绝重复值的INSERT/UPDATE操作，相当于内置了一层数据完整性保护。普通索引则完全不干预写入逻辑，哪怕千万条记录全相同也能成功插入。
- 建表时加唯一索引：CREATE TABLE user (id INT PRIMARY KEY, email VARCHAR(100) UNIQUE);
- 已有表添加唯一索引：ALTER TABLE user ADD UNIQUE INDEX uk_email (email);
- 尝试插入重复邮箱会直接报错：Duplicate entry 'a@b.com' for key 'uk_email'
查询性能表现接近，但优化器可能更倾向使用唯一索引
在等值查询（WHERE column = ?）场景下，两者B+树结构一致，IO和CPU开销基本相同。但优化器知道唯一索引返回结果最多1行，可能选择更激进的执行计划——比如跳过排序、提前终止扫描、或在JOIN中作为驱动表优先匹配。
- 查单个邮箱：SELECT * FROM user WHERE email = 'x@y.com'; → 唯一索引可确认“至多1行”，优化器不考虑回表后去重
- 查普通索引字段：SELECT * FROM user WHERE status = 1; → 可能返回成千上万行，优化器需预留扩展空间
适用场景明确分工：用唯一索引保数据质量，用普通索引提查询效率
唯一索引适合天然具备唯一语义的业务字段，如手机号、身份证号、订单号、邮箱、用户名等。这些字段一旦重复，往往代表脏数据或逻辑错误，必须拦截。普通索引更适合高频查询但允许重复的字段，如状态（status）、分类（category_id）、创建时间（created_at）等。
- ✅ 推荐用唯一索引：用户表的phone、商品表的sku_code、支付表的trade_no
- ✅ 推荐用普通索引：日志表的level、订单表的user_id（一个用户多订单）、文章表的tag_id
- ⚠️ 避免滥用唯一索引：如给nickname加唯一索引，看似防重名，实则限制产品灵活性（昵称可重复）
联合索引中的“唯一”只作用于组合值，不是单列
唯一联合索引（如UNIQUE (user_id, order_time)）保证的是两列值的组合不重复，而非每列单独唯一。这意味着同一个user_id可以有多条记录，只要order_time不同即可；同样，同一order_time也可属于不同user_id。
- 合法：(1001, '2024-01-01 10:00:00'), (1001, '2024-01-01 10:00:01')
- 非法：(1001, '2024-01-01 10:00:00'), (1001, '2024-01-01 10:00:00') → 组合重复
- 普通联合索引无此限制，但依然能加速WHERE user_id = ? AND order_time > ?这类查询
