我将本地化的字符串存储在使用MS Sql（2008或其他）的单个数据表中。大多数字符串都很短，可以用varchar（200）表示，而大约10％的字符串需要varchar（5000）之类的东西。我的问题是，是否有更短的检索字符串时，性能上的优势，如果我打破了这种成两个表是这样的：SQL nvarchar性能
CREATE TABLE ShortTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(200))
CREATE TABLE LongTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))
对战：
CREATE TABLE TextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))
这些数据将很少更新，我只是很真正关心读取。
这取决于。可能是过早的优化。
对于较小的列，很明显，每页将显示更多的行，但是您的使用模式可能意味着您提议的水平分区效率不高，因为它从两个新表中获取内容。我想我们需要看到读取的使用模式以及表格的连接方式。
而且，它是分区的空间在逻辑上是一个空间，将不再管理为一体的空间（即在两个地方添加索引等）
你真的要还得看瓶颈和配置文件提出的变化之前，我会这样分区。
我不确定，但它可能是字面分区（使用SQL Server的分区表功能）基于列的长度的表。再次，这是否会有所帮助需要进行分析。
不，没有真正的收益。为了看到由于字符串大小交错造成的瓶颈，特别是基础不使用int PK，这将是一个真正的极端。
另一方面，使用这样的存储模式的混乱是非常清楚和现在：你必须根据字符串的长度来决定你还没有检索在哪张表上看！您可能最终会通过试验和错误（尝试一个表，然后另一个表），这比任何表nvarchar存储结构问题浪费得多。
在SQL 2005中，我相信2008你不会创建一个NVarChar（5000），因为你超过了这种数据类型的页面大小，NVarChar（Max）会在那个时候工作。当为nVarChar指定一个数字N时，您的限制可达4000.
我相信在这一点上，读取内联存储值与页面之间会有性能差异，读取页面以获取16字节指针指向LOB页面并从那里读取数据。
否或负增益，
寄存明智： 一种可变长度的字符串被存储作为字符+ 2个字节用于长度的数目。所以：数据的长度是相同的，但是你有第二个表的索引和键值开销。
加工明智：
现在，更重要的是，我看到你提到的本地化，但你需要nvarchar？另一个SO问题：varchar vs nvarchar performance
关于过早优化的好处。出于这个原因，我会坚持单桌设计。 – Paul 2009-07-13 19:23:52
另一个问题是，使用2个表格，您将不再能够轻松创建单个外键约束。 – 2009-07-13 21:01:42