0

我在 SQL Server 2012 上有一个数据库，并且在一些表在一段时间后变慢时遇到了一些问题，而有助于重建索引的事情。我想知道是否有人对其中任何一个可能出现的问题提出建议，我将在下面发布它们的结构和索引。我自己没有建立这个结构，但有完全的修改权限。

表格1

  • ID（整数，非空）
  • 类型（tinyint，不为空）
  • 名称（PK，nvarchar(255)，不为空）
  • fkID（PK，int，不为空）
  • UID（整数，不为空）

索引：

  • I_UID（唯一，非集群）[UID]
  • I_Name（非唯一，非集群）[类型，名称]
  • pk_Name（集群）[名称，fkID]

表2

  • ID（PK，bigint，不为空）
  • 名称（nvarchar(50)，不为空）
  • 短值（nvarchar（250），空）
  • StringValue (nvarchar(max), null)
  • 整数值（整数，空）
  • 浮点值（浮点数，空）
  • 日期时间值（日期时间，空）
  • 布尔值（位，空）
  • fkPID (FK, int, null)
  • fkAID (FK, int, null)
  • fkAGID (FK, int, null)
  • fkVID (FK, int, null)
  • fkCID (FK, int, null)
  • fkL（FK，整数，不为空）
  • fkIMID（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，不为空）
  • fkPID (FK, int, not null)
  • fkAID (FK, int, 不为空)
  • 排序（int，非空）
  • 组（nvarchar（50），空）
  • 大小（整数，空）
  • FMB（nvarchar（50），空）

索引：

  • PK_D（集群）5447370
  • I_PAA（非唯一，非集群）[fkAID]
  • I_PAP（非唯一，非集群）[fkPID]
  • I_PAPID（非唯一，非集群）[fkPID,fkAID]
4

3 回答 3

5

让我印象深刻的一栏是这一栏：

pk_Name (Clustered) [Name, fkID]

聚集键确定数据库表中记录的物理顺序。如果Name是一个字符串并且值以“随机”顺序插入（即并不总是按字母顺序在表的末尾），则可能会出现性能问题，因为数据库总是必须将行“插入”到物理表中。这可能会导致表数据变得碎片化，这也可能会降低性能。

重新构建聚集索引还会重新组织物理数据，这可能是您之后看到性能提高的原因。重新计算统计数据也可能是一个因素，但导致非连续插入的主键通常是一个危险信号。

此外，您的定义没有指定构成表 2 和 3 上的聚集索引的列，而是基于我假设它们被索引的名称ID。

于 2013-07-09T13:49:06.793 回答
2

Ola Hallengren 的索引和统计维护工具/脚本是一个很好的工具，可以分析并在必要时重建索引和更新统计信息。我们每晚运行这个东西，以及完整性检查，以保持我们的数据库健康。

http://ola.hallengren.com/

于 2013-07-09T15:12:06.033 回答
1

我遇到了类似的问题。当您将数据添加到表中时，仅当您通过此处所述的特定更改阈值时，才会更新统计信息：

http://blog.sqlauthority.com/2010/04/21/sql-server-when-are-statistics-updated-what-triggers-statistics-to-update/

除了对我们使用数据库的方式进行重大更改之外，我还没有找到任何克服这个问题的好方法。同时你可以运行

UPDATE STATISTICS <Table Name>

或者

alter INDEX <Index Name> ON <Table Name> rebuild

每晚

于 2013-07-09T13:19:04.437 回答