D A T A B A S E M A N A G E M E N T

Improving Performance
with
SQL Server 2000
Indexed Views
By Gail Erickson, Lubor Kollar, and Jason Ward

The SQL Server 2000 Enterprise Edition introduced the new indexed views
capability. This article explains indexed views, describes specific scenarios
in which they enhance performance, and provides guidelines for designing
effective indexed views.

M icrosoft SQL Server has supported the ability to create

virtual tables, known as views, for many years. These
views are used primarily to restrict users to a certain subset of
data in one or more base tables for security reasons, and to
enable developers to customize how users can logically view
data stored in base tables.
The functions of these views have been expanded in
the SQL Server 2000 Enterprise and Developer Editions
to provide system performance benefits. The ability to
create a unique clustered index on a view, as well as non-
clustered indexes, can improve data-access performance
on the most complex queries. In SQL Server 2000, a view
that has a unique clustered index is known as an indexed
view. Note: Indexed views are a feature of SQL Server
2000 Enterprise Edition and SQL Server 2000 Developer
Edition only.
From a database management system (DBMS) perspec-
tive, a view is a description of the data, or metadata. When a
typical view is created, the metadata is defined by encapsu-
lating a SELECT statement that defines a result set, which is
represented as a virtual table. When a view is referenced in
the FROM clause of another query, this metadata is retrieved
from the system catalog and expanded in place of the view’s
reference. After view expansion, the query optimizer com-
piles a single execution plan for the query.
Nonindexed views are materialized at runtime. Any com-
putations such as joins or aggregations are done during query
execution for each query referencing the view. After a
unique clustered index is created on the view, the view’s
result set is materialized immediately and persists in physical
storage in the database. This saves the overhead of repeat-
edly performing this operation at execution time.
The indexed view can be used in a query execution
in two ways. The query can reference the indexed view
directly, or, more importantly, the query optimizer can
select the view if it determines that substituting the view
for some or all of the query is more efficient. In the second
case, the indexed view is used instead of the underlying
tables and their ordinary indexes. The view does not need
to be referenced in the query for the query optimizer to use
it during query execution. This allows existing applications
to benefit from newly created indexed views without
changing these applications.
Performance Gains from Indexed Views
Using indexes to improve query performance is not a new
concept; however, indexed views provide additional perfor-
mance benefits that cannot be achieved using standard
indexes. Indexed views can increase query performance in
the following ways:

66 PowerSolutions
■ Aggregations can be precomputed and stored in the index to
minimize expensive computations during query execution.
■ Tables can be prejoined and the resulting data set stored.
■ Combinations of joins or aggregations can be stored.
Figure 1 demonstrates typical performance increases
achieved when the query optimizer uses an indexed view.
The represented queries varied in complexity, including the
numbers of aggregate calculations, tables used, and predi-
cates. They also included large multimillion-row tables from
a real production environment.
Using Secondary Indexes on Views
Secondary, nonclustered indexes on views can provide addi-
tional query performance. Similar to secondary indexes on
tables, secondary indexes on views may provide more options
for the query optimizer to choose from during the compila-
tion process. For example, if the query includes columns not
covered by the clustered index, the optimizer can choose one
or more secondary indexes in the plan and avoid a time-
consuming full scan of the indexed view or base tables.
Adding indexes to the schema increases the overhead on
the database because the indexes require on-going main-
tenance. Careful consideration should be given to finding
the right balance of indexes and maintenance overhead.
Benefits of Using Indexed Views
Administrators should analyze the database workload before
implementing indexed views. Knowledge of the range of
queries and of various tools (for example, SQL Profiler)
helps identify the queries that can benefit from indexed
views. Frequently occurring aggregations and joins are the
best candidates for indexed views.
Not all queries benefit from indexed views. Similar to ordi-
nary indexes, if indexed views are not used by the query, there
Original Query Times
200 With Indexed Views
150
Time (seconds)
100
50
0 query. These conditions correspond to a single FROM clause
1 2 3 4
Query Number
Figure 1. Performance Results with Indexed Views
www.dell.com/powersolutions
is no benefit. In this case, not only are performance gains unre-
alized, but the additional costs of disk space, maintenance, and
optimization are incurred. However, when indexed views are
used, they can provide significant improvements (by orders of
magnitude) in data access. This is because the query optimizer
uses the precomputed results stored in the indexed view, which
substantially reduces the cost of the query execution.
The query optimizer considers indexed views only for
queries with nontrivial costs. This avoids situations where
trying to match various indexed views during the query opti-
mization costs more than the savings achieved by indexed-
view usage. Indexed views are rarely used in queries with a
cost of less than one unit of execution time.
Applications that benefit from the implementation of
indexed views include:
■ Decision support workloads
■ Data marts
■ Online analytical processing (OLAP) stores and sources
■ Data mining workloads
Applications that may benefit from indexed views usually
contain these types of queries and patterns:
■ Joins and aggregations of large tables
■ Repeated patterns of queries
■ Repeated aggregations on the same or overlapping sets of
columns
■ Repeated joins of the same tables on the same keys
■ Combinations of the above
On the other hand, online transaction processing
(OLTP) systems with many writes or databases with frequent
updates may not be able to take advantage of indexed views
because of the increased maintenance costs incurred by
updating both the view and underlying base tables.
Query Optimizer Selects Indexed Views
The SQL Server query optimizer automatically determines
when an indexed view can be used for a given query execu-
tion. The view does not need to be referenced directly in the
query for the optimizer to use it in the query execution plan.
Therefore, existing applications may take advantage of the
indexed views without any changes to the application itself;
only the indexed views have to be created.
Optimizer Considerations
The query optimizer considers several conditions to deter-
mine if an indexed view can cover a portion or all of the
5
in the query and consist of the following:
■ The tables in the query FROM clause must be a superset of
the tables in the indexed view FROM clause.
PowerSolutions 67
 ■ The join conditions in the query must be a superset of the
join conditions in the view.
■ The aggregate columns in the query must be a subset of
the aggregate columns in the view.
■ All expressions in the query SELECT list must be deriv-
able from the view SELECT list or from the tables not
included in the view definition.
■ The query search condition predicates must be a superset of
the search condition predicates in the view definition.
Each conjunct in the view search predicate must appear in
the same form as a conjunct in the query search predicate.
When this option is used, the query optimizer ignores all
view indexes when estimating the low-cost method of cover-
ing the columns referenced in the query.
Design Considerations: Performance versus Overhead
Identifying an appropriate set of indexes for a database
system can be complex. While there are numerous possibili-
ties to consider when designing ordinary indexes, adding
indexed views to the schema dramatically increases the com-
plexity of the design and the potential results. For example,
indexed views can be used on:
■ Any subset of tables referenced in the query

All columns in the query WHERE clause that belong to ■ Any subset of the conditions in the query for that subset

tables referenced by the view must appear in at least one of of tables

the following: ■ Grouping columns

■ The same predicate in the view definition ■ Aggregate functions, such as SUM

■ A GROUP BY list in the view definition

■ The view SELECT list if there is no GROUP BY Indexes on tables and indexed views should be
designed concurrently to obtain the best results from each
If the query contains more than one FROM clause, such construct. Since both indexes and indexed views may be
as subqueries, derived tables, or UNION, the optimizer may useful for a given query, designing them separately can
select several indexed views to manage a lead to redundant recommendations that
query with multiple FROM clauses. There incur high storage and maintenance over-
are exceptional situations when the opti- head. While fine-tuning the physical
mizer may collapse two FROM clauses into
While fine-tuning the design of a database, trade-offs must be
one (subquery to join, or derived table to physical design of a made between the performance require-
join transformation). If that happens, the ments of a diverse set of queries and
indexed view substitution may cover more database, trade-offs must updates that the database system must sup-
than one FROM clause in the original port. Therefore, identifying an appropriate
query. The recommended best practice is be made between the per- physical design for indexed views is a chal-
to allow the query optimizer to determine lenging task, and the Index Tuning Wizard
which indexes, if any, to use in the query
formance requirements of a should be used whenever possible.
execution plan. diverse set of queries and Query optimization cost can increase
substantially if there are many indexed
Using the NOEXPAND Option updates that the database views that may be considered for a particu-
The NOEXPAND option forces the query opti- lar query. A query optimizer may consider
mizer to treat the view like an ordinary table system must support. all indexed views that are defined on any
with a clustered index. In this case, the subset of tables in the query. Each view has
indexed view must be referenced directly in to be parsed and then investigated for the
the FROM clause. For example: potential substitution before it is rejected. This may take
some time, especially if there are hundreds of such views
SELECT Column1, Column2, ... FROM Table1, relevant to a given query.
View1 WITH (NOEXPAND)WHERE ... A view must meet several requirements before a unique
clustered index can be created on it. During the design
Using the EXPAND VIEWS Option phase, consider these requirements:
Alternatively, the user can explicitly exclude indexed views ■ The view, and all tables referenced in the view, must be

from consideration by using the EXPAND VIEWS option at in the same database and have the same owner.
the end of the query. For example: ■ The indexed view does not need to contain all the tables

referenced in the query to be used by the optimizer.

SELECT Column1, Column2, ... FROM Table1, ■ A unique clustered index must be created before any

View1 WHERE ...OPTION (EXPAND VIEWS) other indexes can be created on the view.

68 PowerSolutions
■ Certain SET options must be set correctly when the base tables from more than one database, a single view cannot
tables, view, and index are created, and whenever data in perform the entire process. However, an indexed view in
the base tables and view are modified. In addition, the each database can perform the aggregation for that data-
query optimizer will not consider the indexed view unless base. If the optimizer can match the indexed views
these SET options are correct. against existing queries, the aggregation processing will
■ The view must be created using SCHEMABINDING, and be faster, without the need to recode the existing queries.
any user-defined functions referenced in the view must Although the join processing is not faster, the overall
also be created with the SCHEMABINDING option. query is faster because it uses the aggregations stored in
■ Additional disk space will be required to hold the data the indexed views.
defined by the indexed view. ■ A frequently executed query aggregates data from several
tables, and then uses UNION to combine the results.
Design Guidelines UNION is not allowed in an indexed view. Views can
Consider these guidelines when designing indexed views: perform each of the individual aggregation operations.
■ Design indexed views that can be used by several The optimizer can then select the indexed views to
queries or multiple operations. For speed up queries that require the aggrega-
example, an indexed view that contains tions. While the UNION processing is not
the SUM of a column and the COUNT_BIG improved, the individual aggregation
of a column can be used by queries that When designing indexed processes are improved.
contain the functions SUM, COUNT,
COUNT_BIG, or AVG. The queries will be
views, keep the index Using the Index Tuning Wizard
faster because only a small number of compact. The optimizer The Index Tuning Wizard recommends
rows from the view need to be retrieved, indexed views and indexes on base tables.
rather than the full number of rows from achieves maximum The wizard enhances an administrator’s abil-
the base tables. Also, a portion of the ity to determine the combination of indexes
computations required for performing the efficiency in locating the and indexed views that optimizes the per-
AVG function will have already been com- formance of the typical range of queries exe-
pleted.
row data when the cuted on a database.
■ Keep the index compact. The optimizer The Index Tuning Wizard forces all the
smallest number of
achieves maximum efficiency in locating required SET options to ensure the result set
the row data when the smallest number columns and bytes is used is correct and that its indexed view creation
of columns and bytes is used in the index. will succeed. Applications may not be able
Conversely, if a large clustered index key in the index. to take advantage of the views if the option
is defined, any secondary, nonclustered settings are not set properly. The inserts,
indexes defined on the view will be sig- updates, or deletes may fail on tables that
nificantly larger because the nonclustered index entries participate in the indexed view definitions.
contain the clustering key in addition to the columns
defined by the index. Maintaining Indexed Views
■ Consider the size of the resulting indexed view. In the The SQL Server automatically maintains indexed views simi-
case of pure aggregation, the indexed view may not pro- larly to any other index. In the case of ordinary indexes, each
vide any significant performance gains if its size is similar index is tied directly to a single table. With each INSERT,
to the size of the original table. UPDATE, or DELETE operation performed on the underlying
■ Design multiple smaller indexed views that accelerate table, the index is updated accordingly so that the values
parts of the process. Designing an indexed view that stored in the index are always consistent with the table.
addresses the entire query is not always possible. In such Indexed views are similarly maintained; however, if the
cases, consider creating several indexed views, each per- view references several tables, updating any of them may
forming a portion of the query. require updating the indexed view. Unlike ordinary indexes,
a single row insert into any of the participating tables may
Consider these examples: cause multiple row inserts into the indexed view. The same
■ A frequently executed query aggregates data in one data- is true for updates and deletes. Consequently, the mainte-
base, aggregates data in another database, and then joins nance of an indexed view may be more expensive than
the results. Because an indexed view cannot reference maintaining an index on the table.

www.dell.com/powersolutions PowerSolutions 69
 In SQL Server 2000, some views can be updated. When
a view is updatable, the underlying base tables are modified
directly through the view using INSERT, UPDATE and
DELETE statements. Creating an index on a view does not
prevent the view from being updatable. For more informa-
tion about updatable views, see “Modifying Data Through a
View” in SQL Server Books Online for SQL Server 2000.
Maintenance Cost Considerations
The following maintenance cost considerations should be
considered when designing indexed views:
■ Additional storage is required in the database for indexed
views. The result set of an indexed view physically per-
sists in the database similarly to a typical table.
■ SQL Server maintains views automatically; therefore, any
changes to a base table on which a view is defined may
initiate one or more changes in the view indexes. Thus,
additional maintenance overhead is incurred.
A view’s net performance improvement is the difference
of the total query execution savings offered by the view and
the cost to store and maintain the view.
It is relatively easy to approximate how much storage a
view will consume. The SQL Query Analyzer tool Display
Estimated Execution Plan is used to evaluate the SELECT
statement encapsulated by the view definition. This tool
yields an approximation of the number of rows returned by
the query and the size of the row. By multiplying these two
values together, it is possible to approximate the potential
size of the view; however, this is only an approximation. The
actual size of the index on the view can only be accurately
determined by creating the index on the view.
The Display Estimated Execution Plan function may give
some insight on the impact of the automated maintenance
overhead. If a statement that modifies the view (UPDATE on
the view, INSERT into a base table) is evaluated with the
SQL Query Analyzer, the SHOWPLAN will include the main-
tenance operations for that statement. This cost multiplied
by the frequency of the operation’s occurrence indicates the
potential cost of view maintenance.
As a general recommendation, any modifications or
updates to the view or the base tables should be performed
in batches rather than as single operations. This may reduce
some view maintenance overhead.
Optimizing Database Performance
The indexed views capability of the Microsoft SQL Server
2000 Enterprise and Developer Editions can significantly
enhance the performance of frequently performed queries
and database applications. Carefully designed indexed
views strike a balance between performance enhancement
70 PowerSolutions
and the views’ storage and maintenance overhead. The
Index Tuning Wizard, the Query Analyzer, and other tools
help administrators achieve this balance by suggesting the
best candidates for indexed views and estimating the over-
head they will incur.
During execution, the query optimizer ensures that the
relevant indexed views are considered and employed, but
only when their use provides significant enhancement. The
query optimizer also enables applications to employ indexed
views without directly referencing the view. This saves the
time and effort of modifying these applications to accommo-
date new indexed views. The potential performance of
indexed views is unlocked by customizing them to the design
and functions of the database.
Gail Erickson is a technical writer for the SQL Server User
Education group at Microsoft. She is responsible for writing
the Creating and Maintaining Databases and Optimizing
Performance sections of SQL Server Books Online. Gail holds a
Master of Music degree from the University of South Dakota.
Lubor Kollar is a program manger in the Microsoft SQL Server
development organization. He is working on the Query Processor
component of SQL Server and also serves as a Microsoft repre-
sentative in the Decision Support subcommittee of the Transaction
Processing Council (TPC). Lubor holds a Ph.D. in Computer
Science from Comenius University in Bratislava, Slovakia.
Jason Ward is a technical lead in the Product Support Services
Database Development team at Microsoft. He is responsible for
ensuring high-quality customer support in the areas of SQL
Server performance, concurrency, and programming. Jason holds
a Bachelor of Science degree in Computer Science from the
College of Charleston in Charleston, South Carolina.
FOR MORE INFORMATION
■ Microsoft SQL Server 2000 Books Online
■ The Microsoft SQL Server Web site at
http://www.microsoft.com/sql
■ Microsoft SQL Server Developer Center at
http://msdn.microsoft.com/sqlserver
■ SQL Server Magazine at
http://www.sqlmag.com
■ The microsoft.public.sqlserver.server and
microsoft.public.sqlserver.datawarehouse newsgroups at
news://news.microsoft.com
■ The Microsoft Official Curriculum courses on SQL Server.
For up-to-date course information, see
http://www.microsoft.com/trainingandservices