聚簇索引强制数据与主键物理绑定，因InnoDB采用索引组织表（IOT）设计，表数据必须依附唯一B+树存在，其叶子节点存完整行记录，非叶子节点仅存键值和指针，确保单次查找即可获取整行，避免回表。
聚簇索引强制数据与主键物理绑定
因为InnoDB采用「索引组织表」（IOT）设计，表数据本身必须依附于一个B+树结构存在——这个结构就是聚簇索引。它不是可选功能，而是InnoDB存储引擎的底层契约：只要建表，就一定有且仅有一个聚簇索引，而它的叶子节点必须存完整行记录。
非叶子节点只存键值和指针，天然腾出空间给数据落位
B+树的设计规则决定了非叶子节点不存任何用户数据，只存索引键（如 user_id）和子节点地址。这带来两个直接结果：
- 单个16KB页能容纳约1170个键值（按
BIGINT主键+6字节指针估算），大幅降低树高 - 所有真实数据被“挤”到叶子层，使叶子页成为唯一承载行记录的位置
这不是为了“方便”，而是B+树结构与磁盘页对齐后，最节省I/O的自然结果。
避免回表才能实现单次B+树遍历拿到全部字段
如果叶子节点只存指针（像MyISAM或InnoDB的二级索引那样），每次主键查询都得先查索引树、再根据指针去另一个地方读数据——这就是回表。而聚簇索引把数据“长在”叶子上，SELECT * FROM users WHERE user_id = 123 只需一次B+树查找就能返回整行。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
这也解释了为什么没有主键时InnoDB会悄悄生成隐藏的 GEN_CLUST_INDEX：它宁可用6字节ROWID撑起一棵B+树，也不能让表脱离聚簇索引模型——否则整个IOT机制就崩了。
二级索引必须携带主键值，根源就在这里
正因为聚簇索引叶子存的是全量行，其他索引（比如INDEX idx_email ON users(email)）就无法再存一遍数据。它的叶子节点只能存两样东西：email值 + 对应的主键（如user_id）。后续查SELECT * FROM users WHERE email = 'a@b.c'时，MySQL先走idx_email拿到user_id，再用这个user_id去聚簇索引里捞整行——这个“再走一次”的动作，就是回表的代价来源。
容易忽略的一点是：如果你在SELECT里只查email和user_id，那idx_email其实已经覆盖了全部需要的字段，不需要回表。这种场景下，哪怕没加INCLUDE，InnoDB也会自动做索引覆盖优化。
