索引设计不佳和缺少索引是提高数据库和应用程序性能的主要障碍, 设计高效的索引对于获得良好的数据库和应用程序性能极为重要. 为数据库及其工作负荷选择正确的索引是一项需要在查询速度与更新所需开销之间取得平衡的复杂任务. 如果索引较窄, 或者说索引关键字中只有很少的几列, 则需要的磁盘空间和维护开销都较少. 而另一方面, 宽索引可覆盖更多的查询. 您可能需要试验若干不同的设计, 才能找到最有效的索引. 可以添加, 修改和删除索引而不影响数据库架构或应用程序设计. 因此, 应试验多个不同的索引而无需犹豫.
SQL Server 中的查询优化器可在大多数情况下可靠地选择最高效的索引, 总体索引设计策略应为查询优化器提供可供选择的多个索引, 并依赖查询优化器做出正确的决定. 这在多种情况下可减少分析时间并获得良好的性能. 若要查看查询优化器对特定查询使用的索引, 请在 SQL Server Management Studio 中的“查询”菜单上选择“包括实际的执行计划”,有关详细信息，请参阅 如何显示实际执行计划.
不要总是将索引的使用等同于良好的性能, 或者将良好的性能等同于索引的高效使用. 如果只要使用索引就能获得最佳性能, 那查询优化器的工作就简单了. 但事实上, 不正确的索引选择并不能获得最佳性能. 因此, 查询优化器的任务是只在索引或索引组合能提高性能时才选择它, 而在索引检索有碍性能时则避免使用它.
索引设计任务
建议的索引设计策略包括以下任务:
-
了解数据库本身的特征. 例如, 它是频繁修改数据的联机事务处理 (OLTP) 数据库, 还是主要包含只读数据的决策支持系统 (DSS) 或数据仓库 (OLAP) 数据库？有关详细信息, 请参阅 联机事务处理与决策支持.
OLTP - 小心使用索引. 每次添加或修改行时, 必须更新索引. 若要避免对经常更新的表进行过多的索引, 索引范围应保持较窄, 可以使用 数据库引擎优化顾问来设计索引.
决策支持系统 - 大量索引, 决策支持系统只需要很少的更新, 但数据量很大, 可使用大量索引提高查询性能.
-
了解最常用的查询的特征. 例如, 了解到最常用的查询联接两个或多个表将有助于决定要使用的最佳索引类型. 有关详细信息, 请参阅 常规索引设计指南
-
了解查询中使用的列的特征. 例如, 某个索引对于含有整数数据类型同时还是唯一的或非空的列是理想索引. 筛选索引适用于具有定义完善的数据子集的列.有关详细信息, 请参阅 筛选索引设计准则
-
确定哪些索引选项可在创建或维护索引时提高性能. 例如, 对现有某个大型表创建聚集索引将会受益于 ONLINE 索引选项. ONLINE 选项允许在创建索引或重新生成索引时继续对基础数据执行并发活动. 有关详细信息, 请参阅设置索引选项
-
确定索引的最佳存储位置. 非聚集索引可以与基础表存储在同一个文件组中, 也可以存储在不同的文件组中. 索引的存储位置可通过提高磁盘 I/O 性能来提高查询性能. 例如, 将非聚集索引存储在表文件组所在磁盘以外的某个磁盘上的一个文件组中可以提高性能, 因为可以同时读取多个磁盘. 有关详细信息, 请参阅 在文件组上放置索引.
或者, 聚集索引和非聚集索引也可以使用跨越多个文件组的分区方案. 在维护整个集合的完整性时, 使用分区可以快速而有效地访问或管理数据子集, 从而使大型表或索引更易于管理. 有关详细信息,请参阅 已分区表和已分区索引. 在考虑分区时, 应确定是否应对齐索引, 即是按实质上与表相同的方式进行分区, 还是单独分区. 有关详细信息, 请参阅 已分区索引的特殊指导原则
有关这些任务的详细信息,请参阅 常规索引设计指南