我们有一个非常大的表(> 77M记录和增长)在SQL Server 2005 64位标准版上运行,我们看到一些性能问题.每天添加的记录多达十万条.
有谁知道SQL Server标准版可以处理的记录数量是否有限制？应该考虑转向企业版还是我们可以使用一些技巧？
附加信息:
有问题的表非常扁平(14列),有一个聚簇索引,有6个字段,另外两个索引在单个字段上.
我们使用3个字段添加了第四个索引,这些字段位于一个问题查询中的选择中,并且没有看到估计性能的任何差异(查询是必须在非工作时间运行的流程的一部分,因此我们没有指标然而).这些字段是聚集索引的一部分.
同意上面的Marc和Unkown ...聚集索引中的6个索引太多了,特别是在只有14列的表上.您不应该有超过3或4,如果是,我会说1或2.您可能知道聚集索引是磁盘上的实际表,因此当插入记录时,数据库引擎必须对它进行排序将它放在磁盘上有序排列的位置.非聚集索引不支持,它们支持查找"表".根据下面的第1点,我的VLDB布局在磁盘上(CLUSTERED INDEX).
将聚簇索引减少到1或2.最佳字段选择是IDENTITY(INT),如果您有一个,或者将字段添加到数据库的日期字段,或者其他一些自然类型的字段如何将数据添加到数据库中.重点是你试图将数据保存在表格的底部......或者以最佳(90%以上)的方式将其放在磁盘上,以便读出记录.这使得它不会进行任何重组,或者只需要一次点击即可将数据放在正确的位置以获得最佳读数.确保将删除的字段放入非聚集索引中,这样您就不会失去查找功能.我从来没有在我的VLDB上放置超过4个字段.如果您有频繁更新的字段,并且它们包含在您的聚簇索引OUCH中,那将重新组织磁盘上的记录并导致COSTLY碎片.
检查索引上的fillfactor.填充因子数(100)越大,数据页和索引页将越多.关于您拥有的记录数和插入的记录数,您将更改非聚集索引的fillfactor#(+或 - ),以便在插入记录时允许填充空间.如果将聚簇索引更改为顺序数据字段,那么在聚簇索引上这将无关紧要.经验法则(IMO),60-70 fillfactor用于高写入,70-90用于中等写入,90-100用于高读取/低写入.通过将fillfactor降为70,意味着对于页面中的每100条记录,将写入70条记录,这将为新的或重组的记录留下30条记录的可用空间.吃掉更多的空间,但它确实每晚都要去DEFRAG(见下面的4)
确保表中存在统计信息.如果要使用"sp_createstats'indexonly'"扫描数据库以创建统计信息,则SQL Server将创建引擎已累积的所有索引的所有统计信息,这些索引需要统计信息.不要忽略'indexonly'属性,否则你将为每个字段添加统计数据,这样就不会好了.
使用DBCC SHOWCONTIG检查表/索引,以查看哪些索引最多碎片化.我不会在这里详细介绍,只要知道你需要这样做.然后根据该信息,相对于索引正在发生变化的变化以及(随着时间的推移)变化,向上或向下更改fillfactor.
设置将在各个索引上联机(DBCC INDEXDEFRAG)或脱机(DBCC DBREINDEX)的作业计划以对其进行碎片整理.警告:如果没有维护时间,请不要在这个大型表上执行DBCC DBREINDEX,因为它会导致应用程序关闭...尤其是在CLUSTERED INDEX上.你被警告过了.测试和测试这部分.
使用执行计划来查看SCANS和FAT PIPES存在的内容并调整索引,然后对存储过程进行碎片整理和重写以消除这些热点.如果在执行计划中看到RED对象,那是因为该字段没有统计信息.那很糟.这一步更多的是"艺术而不是科学".
在非高峰时间,运行UPDATE STATISTICS WITH FULLSCAN为查询引擎提供尽可能多的有关数据分布的信息.否则,在工作日期间对表进行标准UPDATE STATISTICS(标准10%扫描),或者更经常地根据您的观察情况进行操作,以确保引擎有更多关于数据分布的信息以便有效地检索数据.
对不起,这太长了,但这非常重要.我只给你这里最少的信息,但会帮助你.对这些要点所使用的策略有一些直觉和观察,这需要你的时间和测试.
无需进入企业版.我这样做是为了通过分区获得之前所说的功能.但我特别喜欢在搜索和在线DEFRAGING和维护方面拥有更好的多线程功能......在企业版中,它与VLDB相比要好得多,也更友好.标准版也不处理与在线数据库一起使用DBCC INDEXDEFRAG.
我要看的第一件事是索引.如果在Management Studio中使用执行计划生成器,则需要查看索引查找或聚簇索引查找.如果您看到扫描,特别是表扫描,则应该查看对通常搜索的列进行索引,以查看是否可以提高性能.
您当然不需要为此迁移到企业版.
你真的需要在一张桌子上访问所有7700万条记录吗？
例如,如果您只需要访问最近X个月的数据,那么您可以考虑创建归档策略.这可用于将数据重定位到存档表,以减少数据量,并随后在"热"表上查询时间.
这种方法可以在标准版中实现.
如果升级到企业版,则可以使用表分区.同样,根据您的数据结构,这可以提供显着的性能改进.分区也可用于实现前面提到的策略,但管理开销较少.
这是一篇关于SQL Server 2005中表分区的优秀白皮书
http://msdn.microsoft.com/en-us/library/ms345146.aspx
我希望我所详述的内容清晰易懂.如果您需要进一步的帮助,请直接与我联系.
干杯,
[有一个包含6个字段的聚簇索引,以及单个字段上的另外两个索引.
在不知道有关字段的任何细节的情况下,我会尝试找到一种方法来使聚集索引更小.
使用SQL Server,所有聚簇键字段也将包含在所有非聚集索引中(作为从非聚集索引到实际数据页面进行最终查找的一种方式).
如果你有6个字段,每个字节8个字节= 48个字节,再加上两个索引乘以7700万行 - 你会看到很多浪费的空间转换成大量的I/O操作(从而降低了性能).
对于聚集索引,它绝对是唯一的,它是唯一的,稳定的,并且尽可能小(最好是单个INT等).
渣
![OSError:[Errno 107]传输端点未连接](https://img.devbox.cn/3cccf/16086/243/63d1fb966cd748b8.png)
京公网安备 11010802040832号 | 京ICP备19059560号-6 