MSQL-聚簇索引与非聚簇索引的比较

聚簇索引的叶子节点存储的是：真实数据

主键作为聚簇索引：

sql 复制代码

CREATE TABLE users (
    id INT PRIMARY KEY,  -- 此主键自动成为聚簇索引
    name VARCHAR(100),
    email VARCHAR(100)
);

无显式主键时的处理：
- 如果表没有定义主键，InnoDB会选择一个唯一的非空索引代替
- 如果没有这样的索引，InnoDB会隐式创建一个6字节的ROWID作为聚簇索引

查找过程需要回表：

sql 复制代码

二级索引查找 -> 找到主键 -> 通过主键到聚簇索引中查找完整数据

sql 复制代码

CREATE INDEX idx_name ON users(name);  -- 创建非聚簇索引

非**聚簇索引的叶子节点存储的是：**索引列值 + 主键值

MyISAM 存储引擎使用的是纯非聚簇索引结构：

特性	InnoDB聚簇索引	InnoDB非聚簇索引	MyISAM非聚簇索引
数据存储位置	索引叶子节点	单独存储，引用主键	单独.MYD文件
索引数量	每表1个	多个	多个
叶子节点内容	完整数据行	主键值	数据文件指针
查找过程	直接获取数据	需要回表	直接通过指针访问数据
主键查询性能	最优(O(1)~O(logN))	需要两次查找	需一次索引查找
范围查询性能	优秀(顺序I/O)	一般	一般

MyISAM 的非聚簇索引：叶子节点存储的数据文件指针（相对于InnoDB非聚簇索引，避免了回表）

思考：

多实例应用从分布式ID服务获取ID后，由于网络延迟、处理速度差异等原因，后获取到的ID可能先提交事务，导致数据库中ID不是严格递增的，而是呈现"插入"形式（即小ID的记录可能出现在大ID之后）

（其实业务能容忍小范围的不一致）

方案1：业务逻辑的提交操作，尽量靠后，避免提前获取id?