我正在设计一个需要针对最大速度进行优化的数据库.

所有的数据库数据都是从我称之为输入数据库的东西中生成一次的(输入数据库包含我正在编辑的数据,主要是谷歌地图的一些折线,标记等).

因此数据库不受编辑,但它需要保存尽可能多的数据,以便快速向用户显示结果(遍布城镇的路线,自定义折线等).

问题是：选择较小的数据类型,例如像smallint over int会提高性能还是会影响它？空间不是一个问题,经过一些快速计算后,数据库不会超过200mb,并且不会有超过100.000行的表(平均值约为5.000).

我问这个是因为我在互联网上阅读了一些文章,有些人说较小的数据类型提高了性能,其他人说这会影响它,因为必须进行额外的处理.我知道对于较小的数据库可能结果不明显,但我对每一点都感兴趣,因为我期待许多请求会触发更多查询.

托管环境将是带有SQL Server 2008 R2的Windows Server 2008 R2.

编辑1：只是举个例子,因为我还没有适当的表格结构：
我将有一张桌子,可以容纳公共交通线路(大约200个左右),由现实生活中的一个唯一编号标识,并且将在各种各样的表格中被引用,并且各种各样的操作正在进行中被制造.这些引用表将保存最大量的数据.

因为线条有唯一的数字,我想到了3个设计的例子：

> PK是数据类型的行号：smallint
> PK是数据类型的行号：int
> PK是不同的(例如身份),行号存储在不同的字段中.
>仅仅是为了争论,因为我在’输入数据库’上使用了这个,不受优化,PK是一个GUID(16字节);如果你愿意,你可以比较一下与其他人相比有多糟糕,如果真的如此

所以请记住,PK将在至少15个表中被引用,其中一些表将有超过50,000行(其余的平均值为5.000,如上所述),这些表将受到不断的查询和操作,而我我对能得到的每一点速度感兴趣.

如果需要,我可以更详细地说明这一点.谢谢

编辑2：另一个与此相关的问题出现在我的脑海中,认为它符合这个讨论：

如果我在.NET应用程序中使用本机SQL查询而不是使用LINQ to SQL,我是否会在此特定方案中看到任何性能改进？我知道LINQ经过了强有力的优化,可以在性能方面产生非常好的查询,但仍然值得一提.再次感谢.

最佳答案 你能指出一些文章说较小的数据类型=更多的处理吗？请记住,即使使用SSD,今天的大多数工作负载都受I / O限制(或受内存限制)而不受CPU限制.

特别是在许多表中将参考PK的情况下,使用可能的最小数据类型将是有益的.在这种情况下,如果那是一个SMALLINT那么我会使用(虽然你说有大约200个值,所以理论上你可以使用TINYINT,它是一半大小并支持0-255).如果您不能100％确定总会有~200个值,那么您需要谨慎行事.一旦你需要256,你将不得不在所有受影响的表中更改数据类型,这将是一个痛苦.因此,有时需要在适应未来增长和挤压当今最绝对的业绩之间进行权衡.如果您不确定您将永远不会超过255或32,000个值,那么我可能只是一个INT.除非你也不知道你不会超过20亿个值,在这种情况下你会使用BIGINT.

INT / SMALLINT / TINYINT之间的差异在磁盘空间中比在性能上更明显. (如果你使用的是Enterprise,那么磁盘空间和性能的差异可以通过数据压缩来抵消 – 特别是当你的INT值都适合SMALLINT / TINYINT时,尽管在后一种情况下它确实可以忽略不计,因为值是唯一的.)另一方面,任何这些和GUID之间的差异在性能和磁盘空间中都会更加明显.马克给了金伯利一些很棒的联系;在2003年的I wrote this article,虽然它有点过时,它确实包含了今天仍然相关的大部分突出点.

有时需要考虑的另一个权衡(尽管不是在您的具体情况下,似乎)是值是否需要在多个系统中是唯一的.这是您可能需要牺牲一些性能以满足业务需求的地方.在很多情况下,人们采取简单的方式并将自己辞去GUID.但是还有其他解决方案,例如身份范围,中央自定义序列生成器,以及SQL Server 2012中的新SEQUENCE对象.回到2010年,当SQL Server 2012的第一个公开测试版发布时.