如果主键总是排序的，我如何以随机顺序存储Guids作为主键。
否，表数据并不总是按照主键的顺序存储，但通常主键有聚集索引，数据总是按照聚集索引的顺序存储。
如果你不希望数据按照主键的顺序存储，你应该使用非聚集索引
请注意，尽管通常按照数据的存储顺序获取数据，但除非使用order by子句，否则无法保证数据的顺序。如果订单很重要，您应该始终指定它应该是什么。
嗯，主键不一定按排序顺序存储在磁盘上。但是聚集索引是。在绝大多数情况下，主键是聚集索引。虽然这并不一定保证对结果进行排序，但只是默认情况下，结果通常按聚集索引进行排序。
如何将Guid按随机顺序存储为主密钥
正是由于这个原因，GUID不能形成好的聚集索引。SQL Server确实有一个称为"顺序GUID"的东西来解决此问题。生成的GUID不会是连续的，但它们是连续的。不过，它有一些警告：
创建一个GUID，该GUID大于自Windows启动以来此函数以前在指定计算机上生成的任何GUID。
如果系统重新启动，则序列将丢失。如果多个系统创建密钥，则序列将丢失。此外，还有一个问题是，我们仍然依赖SQL Server来生成密钥，这有点违背了使用GUID的重要原因。
一般来说，我建议不要使用GUID作为聚集索引。作为替代方案，可以使用普通的IDENTITY键作为聚集索引，并创建一个单独的GUID列（可能有自己的索引，甚至有一个唯一的约束，以确保应用程序不会试图重新插入现有记录）。从更商业逻辑的意义上讲，这个单独的列变成了一种"全局标识符"，而不是从数据持久性实现的意义上。
没有主键总是按排序顺序存储。
聚集索引也不总是按排序顺序存储，这与流行的误解相反。
如果您选择一个随机GUID作为聚集主键，那么您很可能很快就会得到一个高度碎片化的聚集索引，随着页面变满并需要拆分，物理和逻辑顺序会出现很大差异。
通常，大多数聚集索引扫描都是按照逻辑（索引键）顺序进行的，遵循的是页面指针，而不是分配（页码）顺序。为了考虑按分配顺序扫描，您必须在读取未提交隔离级别运行，或者必须持有表锁。
然而，如果没有顺序，就无法保证结果的顺序。