没有更新的SQL快速插入

我们在SQL Server 2008数据库中使用单个表进行审计。没有更新的SQL快速插入

单表体系结构很好地工作，很容易查询，适应模式更改。

但它是整个数据库的主要瓶颈。所有INSERTS和UPDATES都必须通过审核表。

我们已经对SELECT语句使用了NOLOCK HINT。

由于此表没有更新，是否有任何改善INSERT语句吞吐量的建议？

来源

2009-08-22 pkario

确保您在表格上具有INT（或BIGINT）IDENTITY主聚簇索引！最好不要使用其他索引（如果可能的话） - 这会降低插入速度。

这是一个常见的误解，即由于表只需要INSERT并且几乎没有读取，所以应该自己“保存”主密钥的麻烦。

与SQL Server索引的女神，金佰利特里普，解释了她出色的博客文章The Clustered Index Debate continues：

镶片在群集表更快（但仅限于“正确”的聚集表），比与一个堆相比。这里的主要问题是，IAM/PFS中的查找确定堆中的插入位置是比聚簇表（其中插入位置已知，由聚簇键定义）慢。当插入表插入表其中定义顺序（CL）和其中的顺序是不断增加。

所以一个右聚集索引可以加快你的插入，在这里是指静态的（不会改变），独特的，尽可能小（INT或BIGINT），最好不断增加（无页拆分和因此没有性能损失）。

此外，如果您的表只获取插入并且没有更新/删除，则应确保在聚集索引上使用100％FILLFACTOR以完全填充这些SQL服务器页面。

马克

来源

2009-08-22 15:25:41

我正在沿着这些路线工作。我有一个IDENTITY CLUSTERED PRIMARY KEY，所以INSERTs真的是APPENDs在最后一页。 100％的填充因子是一个很好的触摸。我正在考虑每月进行一次维护，将记录移到“永久性”历史记录表中，以便主表永远不会变大。 – pkario 2009-08-22 15:46:11

好吧，如果你的索引不断增加，即使表的大小真的不是什么大问题（显然除了选择） – 2009-08-22 15:49:37

唯一的建议，我会做是：

确保您从编写非字符串值尽可能
通过存储过程封装你写入审计
抢任何其他数据存储过程调用或
考虑在您的审计存储过程中使用一个单独的仅用于此目的的视图。确保其连接尽可能少。这个视图将用于查找审计消息的PK等，当试图找到您的字符串数据的FK。
不是一个建议，但一个事实：较少的索引意味着更快的插入+较慢的选择。
考虑将旧的审计行归档到另一个表中。保持审核表尽可能小。将这些较旧的审计行移到另一个表。对于报告/查询，请创建一个视图，该视图将join或union“实时”和“较早”的审核。

来源

2009-08-22 15:16:12

如果你只附加到审计表和运行要总是最后执行表扫描报告，认为在表中删除任何索引。

来源

2009-08-22 15:29:29

没有更新的SQL快速插入

回答

相关问题