SQL*_*er8 6 performance database-design sql-server fragmentation
我最近发现可能解释了我缓慢的 SQL 运行时间。
我发现 SSMS 中的默认设置是允许 mdf 一次增长 1MB。当一个表的大小大约为 23 GB 时,这是一个非常大的问题。结果是我有一个严重碎片化的表(并且可能整个数据库都严重碎片化)。它使更新速度非常慢,因为 SQL 必须在写入之前首先为更新创建空间。为了运行更新,它必须每次在执行计算之前将数千条 1 MB 的信息拼凑在一起。
所以我的问题:有没有办法解决这个问题和碎片整理?我已经进入属性 - 文件并将 mdf 增长级别重置为 100MB,并且数据库恢复很简单。我可以进行碎片整理,还是需要进入并重新创建表,或重新创建整个数据库?我知道这会花费很多时间和工作,但我对这个数据库的主要目标是时间效率。它需要尽可能快,如果这意味着从头开始,那就这样吧。
此外,我注意到我可以创建“文件组”,而不是拥有一个非常大的 mdf。我知道这类似于保存多个 mdf;每个表,甚至索引一个。如何安全地创建这些文件组,它们是否也有助于优化查询时间和效率?
如果表上有聚集索引,对表进行碎片整理的最快方法是删除并重新创建聚集索引。在 SQL Server 2005 之前的版本中,您可以使用 DBCC INDEXDEFRAG 命令对标准索引进行碎片整理:
http://msdn.microsoft.com/en-us/library/ms177571.aspx
或者,在 SQL Server 2005 及更高版本上更首选的方法是使用 ALTER INDEX 语句:
http://technet.microsoft.com/en-us/library/ms188388.aspx
如果表上根本没有索引,那么您将需要使用 Windows 对文件进行碎片整理(尽管这不会移动文件中的数据 - 它只会使文件的片段彼此更靠近。)
至于文件组问题;当文件位于不同的磁盘上时,多个文件有助于提高性能。这是因为您可以利用并发读/写。人们普遍认为,将大型索引放在与其所属表不同的驱动器上的不同文件中是一种良好的做法。
我希望这可以帮助你。
| 归档时间: |
|
| 查看次数: |
2499 次 |
| 最近记录: |