我在SQL Server 2012上有一个数据库,有几个表在一段时间后变得很慢,这有助于重建索引。我想知道是否有人对其中任何一个可能存在的问题有建议,我会在下面发布他们的结构和索引。我自己没有建造这个结构,但可以完全修改。
表1
- ID(int,不为null)
- 类型(tinyint,不为null)
- 名称(PK,nvarchar(255),不为空)
- fkID(PK,int,非null)
- UID(int,非null)
索引:
- I_UID(唯一,非群集)[UID]
- I_Name(非唯一、非聚集)[类型、名称]
- pk_Name(群集)[名称,fkID]
表2
- ID(PK,bigint,不为空)
- 名称(nvarchar(50),不为空)
- ShortValue(nvarchar(250),null)
- StringValue(nvarchar(max),null)
- IntValue(int,null)
- 浮点值(float,null)
- DateTimeValue(datetime,null)
- BoolValue(位,空)
- fkPID(FK,int,null)
- fkAID(FK,int,null)
- fkAGID(FK,int,null)
- fkVID(FK,int,null)
- fkCID(FK,int,null)
- fkL(FK,int,非null)
- fKIID(FK,不为空)
- fkPRID(FK,int,null)
- fkNID(int,null)
索引:
- I_AG(非唯一、非群集)[fkAGID]
- I_IM(非唯一、非聚集)[fkIMID]
- I_R(非唯一,非聚集)[fkPRID]
- PK_D(群集)5447370
- I_PDL(非唯一、非聚集)[fkL]
表3
- ID(PK,int,不为null)
- fkPID(FK,int,非null)
- fkAID(FK,int,非null)
- 排序(int,不为null)
- 组(nvarchar(50),null)
- 大小(int,null)
- FMB(nvarchar(50),null)
索引:
- PK_D(群集)5447370
- I_PAA(非唯一、非群集)[fkAID]
- I_PAP(非唯一、非群集)[fkPID]
- I_PAPID(非唯一、非群集)[fkPID、fkAID]
让我印象深刻的一列是:
pk_Name (Clustered) [Name, fkID]
聚集键确定数据库表中记录的物理顺序。如果Name
是一个字符串,并且值以"随机"顺序插入(即不总是按字母顺序在表的末尾),则可能存在性能问题,因为数据库总是必须将行"插入"到物理表中。这可能会导致表数据变得支离破碎,这也可能降低性能。
重新构建聚集索引还可以重新组织物理数据,这可能是您看到性能提高的原因。重新计算统计数据也可能是一个因素,但导致非连续插入的主键通常是一个危险信号。
此外,您的定义没有指定构成表2和表3上聚集索引的列,而是基于名称,我假设它们由ID
索引。
http://ola.hallengren.com/
我遇到了类似的问题。当您将数据添加到表中时,只有当您通过此处所述的特定更改阈值时,统计信息才会更新:
http://blog.sqlauthority.com/2010/04/21/sql-server-when-are-statistics-updated-what-triggers-statistics-to-update/
除了对DB的工作方式进行重大更改外,我还没有找到任何好的方法来克服这个问题。同时你可以运行
UPDATE STATISTICS <Table Name>
或
alter INDEX <Index Name> ON <Table Name> rebuild
每晚