关于数据库主键性能差异
比较对象：（自增主键、有序uuid、无序uuid）
前置条件：根据自增主键、有序uuid、无序uuid相同环境相同条件新增3张测试表，分别向每张表插入5020000数据
1、插入性能：
插入耗时对比：
- 自增：91257ms
- 有序uuid：98779ms
- 无序uuid：275468ms
2、对比页的分裂数
-
自增page_count：61993
-
有序page_count：71857
-
无序page_count：100417
3、对比表占用的大小
-
自增Table Size (MB)：484.320312
-
有序Table Size (MB)：561.382812
-
无序Table Size (MB)：784.507812
空间性能三项对比：自增 > 有序uuid > 无序uuid
造成如此差异原因：
参考ABP.Vnext 原话（https://docs.abp.io/zh-Hans/abp/latest/Guid-Generation）：
使用默认的Guid.NewGuid()带来的影响：
- 空间的浪费以及由此带来的读写效率的下降。
- GUID的生成是基于算法和计算机的唯一标识符(如MAC地址) 等因素。由于GUID的生成不是连续的，因此在将其用作表的主键并设置为聚集索引时，插入新记录可能需要对已存在的记录进行重新排序，为当插入新记录时，数据库系统需要将数据页重新排序，以便为新记录腾出空间。这可能涉及到数据页的分裂或合并操作，这些操作会导致额外的磁盘1/0和处理开销。
- 由于在存储设备上的物理位置不连续，从而导致存储碎片化（page数据分裂太多，页不完整）。影响查询性能，因为数据库需要在磁盘上跳跃访问不连续的数据块
- 当使用GUID作为主键并将其设置为聚集索引时，每次插入新记录时，都可能导致已有记录的物理位置发生改变
因为数据库索引是由B+树组成的：对比有序id和无序id，插入过程图解
插入过程：
有关页合并与分裂图解文章参考：