我正在阅读有关优化数据库性能的索引,并希望在应用索引方面收集各种数据库情况的最佳实践。
使用包含非平凡数量的表和行的完全非索引数据库,您在确定将哪个索引应用于哪种类型的列以实现最大性能时使用了哪些规则?什么查询分析要使用的技巧?
首先,我得到了:(来自http://asptutorials.net/SQL-Server/tutorial-on-indexes/)
对于主要或“标题”表(例如发票表),请在表的主键上创建聚簇索引。
对于辅助或“详细信息”表(例如“invoice_row”),在外键上创建聚簇索引,将子记录组合在一起(在此示例中为“invoice_id”)。这是因为invoice_row表上的大多数查询都将以invoice_id顺序而不是invoice_row_id顺序进行。
对于所有表,在表的每个外键上创建一个非聚集索引。此时不要关心覆盖索引。 考虑一下您将在表上执行的选择查询。您将使用什么样的“where”和“order by”语句?在这些列上创建非聚集索引。
现在是时候开始计时您的典型查询并寻找任何慢查询。如果您确定一个特别慢的,请查看是否有一种方法可以向索引添加额外的非键列,以便它成为该查询的覆盖索引。
我们可以收集哪些其他“经验法则”?使用什么工具?
答案 0 :(得分:3)
我尝试创建我需要的索引,并在测试或生产环境中使用以下脚本来进一步调整索引。我也有其他几个程序,但这个程序开了个好头。请记住,您必须自己选择最佳的列顺序。
这个问题类似于this question,其中我发布了一些用于调整索引的其他存储过程。
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
答案 1 :(得分:2)
1号 - 分析你的SQL。
您需要查看在数据库中抛出的SQL,以确定哪些索引可能有用。仅通过查看计划分析器,您无法确定所需的内容。
2号 - 表空间扫描往往是好事!如果表格“小”或您正在访问30%或更多行,则扫描通常是最有效的访问路径。
3号 - 索引“小”表是没有意义的。
Number 4 - 索引也可用于检索。通常将转换后的值转换为索引的后面 - 通常数据库只会从索引中选择值而不会费力地检索实际行。例如如果常见的SQL是“select max(item_no),其中invoice =?”如果您使用发票和item_no 构建索引,则可以满足查询,而无需访问实际表。
“小”的当前值约为2000行。
永远记住,对于您构建的每个索引,INSERT都会受到严重的性能损失。
答案 2 :(得分:1)
一旦定义了主键和外键索引,就需要分析数据库的事务活动,以确定适当的索引策略。
SQL Server实际上建议您通过多种方式将索引合并到数据库中:
我建议您执行测试以模拟您期望的事务性工作负载,以便准确地设计和调整数据库。