唯一索引因需校验唯一性而强制磁盘随机读、绕过change_buffer，导致写性能下降；普通索引可利用change_buffer缓存更新、减少I/O；NULL使唯一索引失效；冗余唯一索引在已幂等场景反增开销。
唯一索引强制触发磁盘随机读，绕过 change_buffer
普通索引更新时能走 change_buffer 缓存，而唯一索引不能——这是性能差异的核心原因。InnoDB 在执行 INSERT/UPDATE 对二级索引的修改前，若目标页不在 buffer_pool 中，唯一索引必须先把该页从磁盘读入内存，才能校验是否违反唯一性约束。这个“先读再判”的过程跳过了 change_buffer，每次写都多一次随机 I/O。
常见现象包括：innodb_buffer_pool_reads 突增、INSERT ... ON DUPLICATE KEY UPDATE 执行缓慢、写吞吐骤降。尤其在机械硬盘（HDD）上，延迟放大更明显；SSD 虽单次延迟低，但高并发离散写仍可感知差异。
普通索引依赖 change_buffer 减少随机读
change_buffer 是 InnoDB 为普通索引专设的优化机制：当目标页不在内存时，它把索引变更暂存在内存（并落盘），等后续读取该页或后台线程 merge 时再批量应用。这省掉了大量随机磁盘读。
实操要点：
-
innodb_change_buffering默认为all，无需改动；若只关注插入性能，可设为inserts -
innodb_change_buffer_max_size默认 25（占 buffer_pool 的 25%），可动态调至 50，但别设 100——会严重挤占查询缓存空间 - 该机制在“写多读少”场景收益最大（如日志表、账单流水）；若写完立刻查，反而增加 merge 开销
NULL 值让唯一索引的“唯一性”失效，导致误判
MySQL 中 UNIQUE 索引允许任意多个 NULL，因为 NULL != NULL。比如给 email 加了 UNIQUE 却没加 NOT NULL，结果插入 10 条 email IS NULL 全成功——业务以为字段必填且唯一，实际已失控。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
检查方式：SHOW CREATE TABLE t，看约束是否含 UNIQUE NOT NULL；否则即使建了唯一索引，也起不到数据一致性保障作用。
应用层已做幂等，再加唯一索引是双输
如果 Java 服务已用分布式锁 + 幂等表 + 事务确保 id_card 不重复，那数据库再加 UNIQUE INDEX uk_id_card (id_card) 就纯属冗余：
- 拖慢写入：失去
change_buffer加速能力 - 增加死锁概率：多个事务争抢同一索引页做唯一校验
- 错误难定位：
Duplicate entry 'xxx' for key 'uk_id_card'容易被误判为数据污染，而非业务逻辑问题
真正需要唯一索引的刚性场景只有两种：外键引用列，或多系统直连 DB 且无法统一幂等控制。
唯一索引的写入开销不是来自 B+ 树结构本身，而是那个无法绕过的“校验动作”——它把原本可异步、批量、内存化的操作，硬生生拉回同步、单条、磁盘 I/O 的路径上。这点在高并发写入场景下，会迅速暴露为瓶颈。
