创建聚集主键索引：默认排序规则及ASC/DESC效率对比

嘿，我来帮你拆解这两个问题：

一、未指定排序方向时的默认规则 #

从你的示例里的Go关键字能看出是用的SQL Server，在它以及大多数主流关系型数据库（比如MySQL的InnoDB引擎）中，当创建聚集主键索引且未显式指定ASC/DESC时，默认的排序方向是ASC（升序）。

你给出的示例代码里明确指定了Name asc, dob asc，这和数据库的默认行为完全一致：

Create table employee ( 
  Name nvarchar(30), 
  City nvarchar(30), 
  Dob date, 
  Constraint pk_employee primary key clustered (Name asc, dob asc) 
) 
Go

二、ASC与DESC的执行效率对比 #

其实从底层存储和核心操作的角度来说，两者的执行效率几乎没有差异：

• 聚集索引的底层是B+树结构，不管是按升序还是降序构建，B+树的查找、插入、删除操作的时间复杂度都是O(log n)，维护成本完全一致。
• 数据库引擎在处理反向排序的查询时，只是会调整遍历B+树的方向，这个额外的开销微乎其微，通常可以忽略不计。

不过有个实际场景的细节需要注意：如果你的业务查询经常和索引的排序方向匹配（比如频繁执行WHERE Name >= 'A' AND Name <= 'Z'这类升序范围查询），那对应的索引排序方向（ASC）会让查询逻辑更直接；反之，如果你的查询大多是降序范围查找，那用DESC的索引会更贴合需求。但这种差异并不是“效率更高”，而是更适配你的查询模式，避免额外的排序反转操作。

另外，对于你示例中的复合聚集索引（Name+Dob），排序方向的组合会影响索引的覆盖能力——比如如果查询需要按Name升序、Dob降序返回结果，那和索引的排序方向（双ASC）不匹配的话，可能需要额外的排序步骤，但这依然不是ASC或DESC本身的效率问题，而是索引设计是否贴合查询需求的问题。

内容的提问来源于stack exchange，提问作者Madhukar