如何确定 SQL Server 2008 R2 上全文索引的大小?
我有一个 SQL 2008 R2 数据库,上面有一些表,其中一些表定义了全文索引。我想知道如何确定特定表的索引大小,以便控制和预测它的增长。
有办法做到这一点吗?
I have a SQL 2008 R2 database with some tables on it having some of those tables a Full-Text Index defined. I'd like to know how to determine the size of the index of a specific table, in order to control and predict it's growth.
Is there a way of doing this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
目录视图
sys.fulltext_index_fragments
会跟踪每个片段的大小,无论目录如何,因此您可以通过这种方式获取SUM
。这假设每个表一个全文索引的限制仍然存在。以下查询将获取数据库中每个全文索引的大小,同样与目录无关,但如果您只关心特定表,则可以使用WHERE
子句。另请注意,如果碎片数量很高,您可能会考虑重新组织。
The catalog view
sys.fulltext_index_fragments
keeps track of the size of each fragment, regardless of catalog, so you can take theSUM
this way. This assumes the limitation of one full-text index per table is going to remain the case. The following query will get you the size of each full-text index in the database, again regardless of catalog, but you could use theWHERE
clause if you only care about a specific table.Also note that if the count of fragments is high you might consider a reorganize.
如果您正在寻找特定目录
使用SSMS
- 单击[数据库]并展开对象
- 点击[存储]
- 右键单击{特定目录}
- 选择属性并单击。
在常规选项卡中..您会发现目录大小='nn'
If you are after a specific Catalogue
Use SSMS
- Clik on [Database] and expand the objects
- Click on [Storage]
- Right Click on {Specific Catalogue}
- Choose Propertie and click.
IN General TAB.. You will find the Catalogue Size = 'nn'
我使用与此类似的东西(它也会计算 XML 索引的大小,...如果存在)
这通常会给出高于 sys.fulltext_index_fragments 的数字,但与
结合使用时表的 sys.partitions
中,它将与从EXEC sys.sp_spaceused @objname = N'schema.TableName';
返回的数字相加。使用 SQL Server 2016 进行测试,但文档表明它应该自 2008 年起就存在。
I use something similar to this (which will also calculate the size of XML-indexes, ... if present)
This will generally give numbers higher than
sys.fulltext_index_fragments
, but when combined with thesys.partitions
of the table, it will add up to the numbers returned fromEXEC sys.sp_spaceused @objname = N'schema.TableName';
.Tested with SQL Server 2016, but documentation says it should be present since 2008.