聚簇索引应优先选择高频查询、范围扫描、ORDER BY 和 JOIN 的字段，而非仅关注唯一性；例如订单表宜选 created_at 或 user_id，而非默认自增 id。
聚簇索引选哪个字段？看查询模式，不是看“唯一性”
聚簇索引决定数据在磁盘上的物理排序，MySQL 的 InnoDB 强制要求每张表有且仅有一个聚簇索引——通常是主键。但很多人误以为“只要唯一+非空就能当主键”，结果查 WHERE status = 'done' 慢得离谱，因为 status 字段根本没进聚簇结构。
真正该优先考虑的是高频查询条件、范围扫描、ORDER BY 和 JOIN 的字段。比如订单表常按 created_at 分页查最新 10 条，或按 user_id 查某人全部订单——这两个字段比自增 id 更适合作聚簇索引（需配合业务权衡）。
- 如果主键是
id（自增），而你总查WHERE user_id = ? AND created_at > ?，那user_id+created_at建联合二级索引更有效，但聚簇仍锚定id，无法避免回表 - 复合主键如
(user_id, created_at)能让同一用户的订单物理连续，大幅提升范围查询效率，但会增大所有二级索引的叶子节点（因要存这个主键值） - UUID 或随机字符串作主键？会导致页分裂严重、插入性能骤降，B+ 树频繁分裂和合并，
INSERT吞吐量可能跌 50% 以上
为什么自增主键不是万能解？它和 B+ 树写放大直接相关
自增主键让新记录总追加到 B+ 树最右叶节点，写入友好，但代价是：所有二级索引的叶子节点都得存这个长整型主键值。如果主键从 BIGINT（8 字节）换成 (user_id, order_no)（比如两个 INT，共 8 字节），体积没变；但若换成 CHAR(36) UUID，每个二级索引条目就多存 36 字节——索引体积翻倍，缓存命中率下降，SELECT 也变慢。
更隐蔽的问题是：高并发下自增锁（auto-inc lock）可能成为瓶颈，尤其批量 INSERT ... SELECT 场景。MySQL 5.7+ 默认用轻量级互斥量替代，但老版本或特定配置下仍卡住。
- 用
SHOW ENGINE INNODB STATUS\G查Auto-inc lock等待，不是所有慢查都怪 SQL 写法 -
innodb_autoinc_lock_mode = 2（交错模式）可提升并发插入，但要求 binlog_format = ROW，否则主从不一致 - 自增主键删除后不会复用，长期运行下
id值巨大，但对 B+ 树结构无实质影响——别为此强行重置
主键被强制替换为聚簇索引时，哪些错误会静默发生？
当你删掉原主键、加新主键，InnoDB 会重建整张表并重排聚簇索引。这过程不报错，但可能引发三类隐性问题：
- 大表执行
ALTER TABLE t ADD PRIMARY KEY (a,b)期间，表不可写，且临时空间占用接近原表两倍（旧数据+新聚簇数据） - 如果新主键含
NULL字段（哪怕定义为NOT NULL但实际有空值），ALTER直接失败，错误信息是ERROR 1138: Invalid use of NULL value，而非“主键不能为 NULL”这种提示 - 已有外键引用原主键？
ALTER会拒绝，报错ERROR 1829: Cannot drop index 'PRIMARY': needed in a foreign key constraint，必须先删外键再操作
别依赖 ORM 自动生成的 id BIGINT PK——它只是默认选项，不是设计结论。
什么时候该放弃主键即聚簇索引？用显式聚簇覆盖查询热点
有些场景，业务上根本不需要“全局唯一 ID”，比如日志表、IoT 设备上报表、消息队列消费位点表。这时硬塞个自增 id 只是增加存储和维护成本。更合理的是用时间分片字段（如 dt）或业务维度（如 tenant_id）做主键，甚至组合成 (dt, tenant_id, seq)，让物理存储天然契合查询路径。
注意：InnoDB 不允许没有主键的表——它会悄悄建一个隐藏的 6 字节 ROW_ID 当聚簇索引，这个 ID 是全局递增但不可见，且无法用于查询或约束，纯属兜底机制，性能不可控。
- 用
SHOW CREATE TABLE t确认主键是否是你设的，而不是空着或显示PRIMARY KEY () - 检查
information_schema.INNODB_SYS_INDEXES中NAME = 'GEN_CLUST_INDEX'表示用了隐藏主键，赶紧补上显式主键 - 分区表（
PARTITION BY RANGE COLUMNS(dt)）和聚簇索引不冲突，但分区键必须包含在主键中，否则建表失败
B+ 树的分支因子、页大小、缓冲池命中率，最终都落在“数据怎么落盘”这一件事上。想调优查询，先看清你的主键是不是真正在服务查询，而不是仅仅满足 DDL 语法。
