SQL Server - 维护索引的最佳实践是什么？
SQL Server - 维护索引的最佳实践是什么？
我正在研究索引以优化数据库性能，并希望就应用索引的各种数据库情况收集最佳实践。
假设一个完全没有索引的数据库，其中包含大量的表和行，你在确定为实现最佳性能而给哪个列的哪个类型应用索引时使用什么规则？你使用什么查询分析技巧？
作为一个起点，我找到了以下内容（来自http://asptutorials.net/SQL-Server/tutorial-on-indexes/）：
- 对于主表或“头部”表，例如发票表，应在表的主键上创建聚集索引。
- 对于次要表或“详细信息”表，例如“invoice_row”，应在将子记录分组在一起的外键上创建聚集索引（在此示例中为“invoice_id”）。这是因为在invoice_row表上的大多数查询将按照invoice_id的顺序进行，而不是按照invoice_row_id的顺序进行。
- 对于所有表，应在表的每个外键上创建非聚集索引。此时不必考虑覆盖索引。
考虑一下您将在表上执行的选择查询。您将使用什么样的“where”和“order by”语句？在这些列上创建非聚集索引。
- 现在是时候开始计时您的典型查询并查找任何缓慢的查询。如果您确定有一个特别慢的查询，请查看是否有办法向索引添加额外的非键列，使其成为该查询的覆盖索引。
我们还可以收集哪些其他“经验法则”？使用什么工具？
SQL Server中如何维护索引的最佳实践？
在定义了主键和外键索引之后，需要分析数据库的事务活动，以确定适当的索引策略。
SQL Server实际上通过多种方式提供了可能有助于你的数据库的索引建议：
1. 通过缺失索引动态管理视图（Dynamic Management Views）来提出可能在你的数据库中缺失的索引。通过审查在你的平台上生成的执行计划，这些索引可以从中受益。
2. 通过数据库引擎调优顾问（Database Engine Tuning Advisor）创建一个SQL Server跟踪来创建一个工作负载文件，然后通过DTA运行该文件，以生成建议。
我建议你进行测试，以模拟你预期的事务工作负载，以便准确地设计和调整你的数据库。
在维护索引时，有一些最佳实践需要遵循。以下是这些最佳实践的原因和解决方法：
1. 分析SQL
需要分析数据库中使用的SQL，以确定哪些索引可能是有用的。仅仅通过查看计划分析器是无法确定所需的索引的。
2. 表空间扫描通常是一个好的选择！如果表的大小较小或者访问了30%或更多的行，则扫描通常是最有效的访问路径。
3. 对于“小”表来说，建立索引是没有意义的。
4. 索引对于检索也是有用的。将常用的检索值附加到索引的末尾，通常数据库只需要从索引中选择值，而不需要访问实际的行。例如，如果常见的SQL是“select max(item_no) where invoice =？”如果你建立了一个包含invoice和item_no的索引，那么查询可以在不访问实际表的情况下得到满足。
“小”表的当前值约为2000行。
始终记住，对于每个建立的索引，插入操作都会有严重的性能惩罚。
SQL Server - 如何维护索引的最佳实践？
当在测试或生产环境中创建所需的索引时，我使用以下脚本来进一步优化索引。我还有一些其他的存储过程，但这个存储过程提供了一个很好的起点。请记住，您必须自己选择最佳的列顺序。
这个问题类似于我在这个问题中发布的一些其他用于优化索引的存储过程。
CREATE PROCEDURE [ADMIN].[spMissingIndexes]
AS
SELECT
mid.statement,
mid.equality_columns,
mid.inequality_columns,
mid.included_columns,
migs.user_seeks,
migs.user_scans,
migs.last_user_seek,
migs.avg_user_impact,
user_scans,
avg_total_user_cost,
avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) AS [weight]
FROM
sys.dm_db_missing_index_group_stats AS migs
INNER JOIN sys.dm_db_missing_index_groups AS mig
ON (migs.group_handle = mig.index_group_handle)
INNER JOIN sys.dm_db_missing_index_details AS mid
ON (mig.index_handle = mid.index_handle)
ORDER BY
avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) DESC ;
GO
以上是一个用于查找缺失索引的存储过程。它使用了sys.dm_db_missing_index_group_stats、sys.dm_db_missing_index_groups和sys.dm_db_missing_index_details系统视图来提供缺失索引的信息。存储过程返回了一些重要的列，包括语句、相等列、不等列、包含列、用户搜索次数、用户扫描次数、最后用户搜索时间、平均用户影响度、用户扫描次数、平均总用户成本和权重。
通过执行这个存储过程，可以获得哪些索引是缺失的，并找到对性能有重要影响的索引。然后可以根据返回的信息来决定是否需要创建这些缺失的索引，以及哪些列应该包括在索引中。
这个存储过程的排序方式是根据权重来进行的。权重是通过计算平均总用户成本、平均用户影响度和用户搜索次数与用户扫描次数之和的乘积得出的。较高的权重意味着索引对性能的影响更大。
维护索引的最佳实践包括定期运行这个存储过程，以识别缺失的索引并采取适当的措施来创建它们。此外，还可以考虑使用其他索引维护方法，例如重新组织索引、重建索引或使用索引优化工具来进一步提高查询性能。
总之，通过使用这个存储过程和其他索引维护方法，可以帮助优化SQL Server数据库的性能，并确保索引的有效使用。