在数据库表结构设计中，索引是优化查询性能、保障数据规范性的重要组件，其中唯一索引和普通索引是最常用的两种索引类型，二者在功能特性和适用场景上存在明显差异，需要结合业务需求合理选择。
基础定义说明
普通索引
普通索引是最基础的索引类型，没有任何约束限制，主要作用是加快数据的查询速度。它允许索引列存在重复的值，也允许列值为空，创建普通索引时不需要对现有数据做唯一性校验。
唯一索引
唯一索引除了具备普通索引的查询加速功能外，还会对索引列的值做唯一性约束，要求索引列的所有值都不能重复，但允许列值为空，且多个空值不视为重复。创建唯一索引时，数据库会自动校验现有数据是否满足唯一性要求，不满足则创建失败。
核心区别对比
二者的核心差异可以从以下几个维度展开对比：
| 对比维度 | 普通索引 | 唯一索引 |
|---|---|---|
| 唯一性约束 | 无，允许重复值和空值 | 有，不允许重复值，允许空值 |
| 创建时校验 | 不需要校验数据唯一性 | 需要校验现有数据唯一性 |
| 查询性能 | 查找到第一条满足条件的记录后继续扫描后续记录 | 查找到第一条满足条件的记录后即可停止扫描 |
| 更新性能 | 仅需要更新索引树，无额外校验 | 更新时需要校验唯一性，可能触发唯一性冲突判断 |
| 适用场景 | 仅需要加速查询、无唯一性要求的字段 | 需要保障数据唯一性、同时需要加速查询的字段 |
代码示例
以MySQL数据库为例，两种索引的创建语法如下：
-- 创建普通索引的两种方式
-- 方式1：建表时创建
CREATE TABLE user_info (
id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50),
age INT,
-- 给username字段创建普通索引
INDEX idx_username (username)
);
-- 方式2：表创建后追加普通索引
CREATE INDEX idx_age ON user_info(age);
-- 创建唯一索引的两种方式
-- 方式1：建表时创建
CREATE TABLE order_info (
order_id INT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32),
user_id INT,
-- 给order_no字段创建唯一索引，保障订单号不重复
UNIQUE INDEX uk_order_no (order_no)
);
-- 方式2：表创建后追加唯一索引
CREATE UNIQUE INDEX uk_user_id_card ON user_info(id_card);
适用场景说明
普通索引适用场景
当字段仅需要提升查询效率，没有唯一性要求时，优先选择普通索引，常见场景包括：
- 用户表的年龄、性别字段，这些字段本身存在大量重复值，不需要唯一性约束，只需要加快按年龄、性别筛选的查询速度。
- 订单表的创建时间字段，经常需要按时间范围查询订单，不需要时间唯一，适合创建普通索引。
- 日志表的类型字段，日志类型重复度高，仅用于查询过滤，适合普通索引。
唯一索引适用场景
当字段需要保障数据不重复，同时需要查询加速时，选择唯一索引，常见场景包括：
- 用户表的手机号、邮箱字段，业务上要求一个手机号、邮箱只能注册一个账号，需要唯一性约束，同时经常需要按手机号、邮箱查询用户信息，适合创建唯一索引。
- 订单表的订单编号字段，订单编号是业务的唯一标识，不能重复，同时经常需要按订单编号查询订单详情，适合创建唯一索引。
- 商品表的商品编码字段，每个商品的编码唯一，经常需要按编码查询商品，适合创建唯一索引。
注意事项
在实际使用中需要注意以下几点：
- 如果字段需要唯一性约束，不要使用普通索引加业务代码校验的方式替代唯一索引，业务代码在高并发场景下可能出现校验失效的问题，唯一索引的约束是数据库层面的，可靠性更高。
- 唯一索引的更新操作会比普通索引多一步唯一性校验，如果字段更新频率极高，且唯一性要求不高，可以权衡是否使用普通索引。
- 主键索引是一种特殊的唯一索引，不允许空值，而普通唯一索引允许空值，二者不要混淆。
合理选择索引类型可以在保障数据准确性的同时，最大化提升数据库的性能，开发者需要结合业务的实际需求，从约束要求、查询频率、更新频率等多个角度综合判断。