更新时优先选普通索引，因其支持Change Buffer可减少随机IO，写延迟降低30%～50%；唯一索引需强制读盘校验唯一性，开销更大；应用层已兜底唯一性时应避免使用唯一索引，仅在多系统直连或作外键引用时才必须使用。
更新时优先选普通索引，除非业务必须由数据库强制防重。
普通索引能用 Change Buffer，唯一索引不能
当目标数据页不在内存中时：
- 普通索引：把 INSERT/UPDATE 操作暂存到 Change Buffer，不读磁盘，语句立刻返回
- 唯一索引：必须先把数据页从磁盘读入内存，校验唯一性后才能写，多一次随机 IO
这个差异在写多场景（如日志表、订单流水、消息队列）中尤为明显——普通索引可降低 30%～50% 的写延迟。
唯一索引的校验开销不止一次 IO
除了强制读盘，唯一性检查本身也更重：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 需要完整走一遍 B+ 树搜索路径，确认无重复值
- 若存在二级唯一索引 + 主键，还可能触发额外的主键查找（用于回表校验）
- 冲突时抛出 Duplicate entry 错误，排查成本高，常被误判为并发 bug
应用层已保证唯一性时，别用唯一索引
比如身份证号、手机号、订单号等字段，如果服务端已通过以下方式兜底：
- 分布式锁（Redis Lock / ZooKeeper）
- 幂等 key + 状态机校验
- 事务内先 SELECT FOR UPDATE 再 INSERT
那数据库层加 UNIQUE 约束就是纯性能损耗，没实际价值。此时建普通索引更轻量、更高效。
必须用唯一索引的两种情况
只有满足以下任一条件，才应选用唯一索引：
- 多套系统直连数据库，无法统一控制写入逻辑
- 该字段要作为外键被其他表引用（InnoDB 要求被引用列必须有 UNIQUE 或 PRIMARY KEY）
