5

我们以两种方式使用 mini profiler：

  1. 在带有弹出窗口的开发人员机器上
  2. 在我们的 staging/prod 环境中，SqlServerStorage 存储到 MS SQL

几周后，我们发现写入分析数据库需要很长时间（几秒钟），并且会在网站上引起真正的问题。截断所有探查器表可以解决该问题。

查看 SqlServerStorage 代码，插入似乎还进行检查以确保具有该 id 的行不存在。这是为了确保与数据库无关的代码吗？随着行数的增加，这似乎会带来巨大的损失。

我将如何从性能分析器中消除性能损失？有没有其他人经历过这种减速？还是我们做错了什么？

为任何帮助或建议而欢呼。

4

1 回答 1

6

嗯，当我忘记默认聚集时，看起来我在创建该MiniProfilers表primary key时犯了一个巨大的错误......聚集索引是一个 GUID 列，一个非常大的禁忌。

因为数据以与聚集索引相同的顺序物理存储在磁盘上（实际上，可以说该表是聚集索引），所以 SQL Server 必须保持每个新插入的行都以该物理顺序排列。当我们基本上使用随机数时，这将成为保持排序的噩梦。

解决方法是添加一个自动增加的 int 并将主键切换到那个，就像所有其他表一样（为什么我忽略了这个，我不记得了......我们在 Stack Overflow 上不使用这个存储提供程序否则这个问题早就被发现了）。

我将更新表创建脚本并为您提供一些东西来迁移您当前的表。

编辑

再看一遍，主MiniProfilers表可能只是一个堆，这意味着没有聚集索引。所有对行的访问都是通过该 guidID列进行的，因此没有物理排序会有所帮助。

如果您不想重新创建 MiniProfiler sql 表，可以使用此脚本使主键成为非聚集的：

-- first remove the clustered index from the primary key
declare @clusteredIndex varchar(50);

select  @clusteredIndex = name
from    sys.indexes
where   type_desc = 'CLUSTERED'
        and object_name(object_id) = 'MiniProfilers';

exec ('alter table MiniProfilers drop constraint ' + @clusteredIndex);

-- and then make it non-clustered
alter table MiniProfilers add constraint 
  PK_MiniProfilers primary key nonclustered (Id);

另一个编辑

好的，我已经更新了创建脚本并为大多数查询添加了索引 -请参阅 GitHub 中的代码。

我强烈建议删除所有现有表并重新运行更新的脚本。

于 2012-12-05T01:50:58.780 回答