sql-server – EF Code First对所有字符串使用nvarchar(max).这会损害查询性能吗？

我有一些使用Entity Framework Code First创建的数据库;应用程序正在运行,总的来说,我对Code First让我做的事情感到非常满意.我是第一个程序员,第二个是DBA,必要时.我正在阅读有关DataAttributes的内容,以便在C#中进一步描述我希望数据库做什么;我的问题是：通过在我的表中使用这些nvarchar(max)字符串,我会吃什么惩罚(参见下面的示例)？

这个特定的表中有几列;在C#中,它们被定义为：

[Key]
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Message { get; set; }
    public string Source { get; set; }
    public DateTime Generated { get; set; }
    public DateTime Written { get; set; }

我期望基于Name,Source,Generated和Written进行查询和/或排序.我希望Name和Source的长度为0-50,偶尔高达150.我希望这个表开始时非常小(<100k行),但随着时间的推移会显着增长(> 1m行).显然,消息可能很小或很大,并且可能不会被查询. 我想知道的是,当我从未期望它们大于150个字符时,我的Name和Source列的性能是否被定义为nvarchar(max)？

解决方法

较大的nvarchar(max)数据项(超过8000个字节左右)将溢出到文本存储中并需要额外的I / O.较小的项目将存储在行中.有一些选项可以控制此行为 – 有关详细信息,请参阅此 MSDN article.

如果存储在行中,则没有显着的I / O性能开销;在处理数据类型时可能会有额外的cpu开销,但这可能很小.

但是,将nvarchar(max)列放在不需要它们的数据库周围是相当差的形式.它确实有一些performance overhead,并且通常数据大小对于理解数据表非常有帮助 – 例如,varchar列50或100个字符宽可能是描述或自由文本字段,其中一个(例如)10-20 chars ling很可能是一个代码.你会惊讶于人们通常会通过这样的假设从数据库中推断出多少意义.

在数据仓库中工作,通常不在支持不良或文档化的遗留系统上,拥有易于理解的数据库模式非常有价值.如果您将数据库视为应用程序的遗留问题,请尝试对将要从您继承数据库的人员表示满意.

原文地址：https://www.jb51.cc/mssql/80448.html