记录大小是否影响SQL性能？

Question

我们的团队正在使用，使用实体框架核心进行访问。

我们有一个表，预计有5-4千万条记录，我们希望对高速记录的创建、读取和更新进行优化。

每一项记录都很小，而且效率很高：

• 5整数(其中之一是索引的主键)
• 3位
• 1 datetime

加2 varchar(128) -比其他列大得多。

在创建过程中填充了两个varchar列，但只在极少数后续读取中使用，而且从未更新过。假设每次创建10次读取和4次更新。

我们的问题是:将这些较大的列放在不同的表中(对create施加连接惩罚，但只对极小一部分的读取施加连接惩罚)，而编写两个存储过程(其中一个用于检索大多数查询的非varchar列，另一个在需要时检索所有列)，会提高性能吗？

换句话说:单个记录大小对SQL性能有多大影响？

Answer 1

是否提高了将这些较大字段放在不同表中的性能(对创建进行连接惩罚，但只有一小部分读取)

一个更好的选择是创建不包括较大列和支持频繁访问模式的索引。

行上较大的列对表上的单行操作的开销很小，但将大大降低聚集索引上的行密度。因此，如果您必须扫描聚集索引，那么有大量未使用的列会增加查询的IO成本。这就是适当的非聚集索引可以将任何扫描操作从聚集索引卸载的地方。

但是，和往常一样，您应该简单地测试一下。40M行很容易生成，然后编写最多的几个查询，并使用不同的索引组合测试它们的性能。

Answer 2

关于:单个记录大小对SQL性能的影响有多大？

这取决于正在执行的查询。例如，在select语句中，如果varchar字段不包含在查询的任何部分中，那么它几乎不会影响性能。

您可以尝试这两种模型并在SSMS中度量查询，使用

SET STATISTICS TIME ON
SET STATISTICS IO ON
GO

或分析数据库引擎优化顾问中的查询。

Answer 3

• 索引三个非NVARCHAR的字段可以帮助
• 它取决于您的读写和更新
• 的组合它取决于您是否附加在表的末尾，例如实时数据收集

。

实体框架很可能不利于数百万行的简单表结构，特别是如果该表与许多其他表无关