Microsoft SQL中的聚集索引创建缓慢（2014）。。。正常吗？

这里潜伏了很久。我注意到，当在两列（客户ID和日期）上的大型数据集（2亿条记录，30-40列）上创建唯一的聚集索引时，系统资源的利用率似乎最低，即使这是一项密集型任务

数据通常按照创建索引的相似或精确顺序进行预排序，但未排序的数据集具有相似的观察结果

a。cpu保持在3%以下（32个逻辑核，maxdop设置为8）

b。标准sql（不支持并行索引计划）

c。磁盘利用率通常低于1MB（磁盘支持500+mbs），超过100mbs的突发时间少于1%

d。网络利用率低于10kbs，但支持1gbs

e。sql上没有其他进程，115GB的ram可用

在临时表或物理表上创建索引时会出现这种情况。只是好奇为什么很多系统资源没有被利用。串行非并行过程是否可能利用最少的资源

服务器设置： A.最小服务器内存：默认值为0 B最大服务器内存115gb C索引创建内存0（默认） D每个查询的最小内存（8192kb，高于默认的1024kb）

使用提示“sortintempdb”并没有产生明显的效果。正在使用基本逻辑： 在test.mydb.mytable（id\u列，date\u列）上创建唯一的群集索引abc

谢谢你的见解

唯一：聚集索引查询计划 插入>聚集索引插入（成本100%）>计算标量>计算标量>计算标量>顶部>常量扫描

有时，如果不是100%预分拣，分拣将在那里以%的成本进行

其他信息：

数据未排序时，索引如下所示： 插入>索引插入（21%成本）>排序（76%成本）>表扫描（3%成本）

排序和插入始终有一个警告：

插入：不解释黄色感叹号。States maxdop=1（我认为sql标准的唯一选项）

排序：提到tempdb溢出数据警告。 “操作员在溢出级别1和1溢出线程的执行期间使用tempdb溢出数据，排序将1826397页写入tempddb，并从tempddb读取1826397页，授予内存21016760kb…”

在创建索引时添加使用tempdb的提示通常会产生不利影响，即使两个驱动器的性能相同（Sql db驱动器和tempdb）

更新：

---

旁注：我经常注意到查询溢出到tempdb中（因为maxdop=8，所以有8个线程），并且在查询优化器中被授予12-16GB的内存。服务器有128GB的ram，其中115GB专用于SQL。当服务器上没有其他查询运行时，它仍然会溢出，这很奇怪。

3%的CPU意味着一个内核固定在32核系统上，对吗？所以它的CPU瓶颈。我发现1MB/s的速度非常慢，尽管.97%的服务器处于空闲状态。。。是因为不允许创建sql标准和并行索引吗？我相信对于非企业索引，maxdop会被值1覆盖。我不知道，但这就是你在问题中所说的。无法使用wp_shoisactive查看索引生成所消耗的CPU时间。这应该与经过的总时间一致99%。这证明它是一个几乎完全受CPU限制的单线程进程。您是否有“wp_shoisactive”的替代命令名，我不认为它是一个实际的表。它可能是亚当·马查尼克的第三方UTI吗？如果可能，我想使用本机查询。不确定，sp_who2是否足够？否则，您将不得不在谷歌上搜索一些随机的“当前正在运行的查询”脚本