Indexed Views
This is an important new feature in SQL Server 2000. You can significantly improve performance by creating a unique clustered index on a view that involves complex processing of large quantities of data, such as aggregating or joining many rows. Calculated values can be indexed, effectively storing the calculation in the database and dynamically maintaining it. Another benefit of creating an index on a view is that the optimizer starts using the view index, even in queries that do not directly name the view in the FROM clause. Existing queries can benefit from the improved efficiency of retrieving data from the indexed view without having to be rewritten.
Indexed views have been available for some time in other relational database management systems, like Oracle, where they are referred to as materialized views. Their inclusion in SQL Server 2000 represents one more area where Microsoft is catching up in features and performance with its more expensive competitors.
How the Query Optimizer Considers Indexed Views - One interesting feature in SQL Server 2000 is that if you have a view with indexes, and the underlying table does not have indexes, the query optimizer might use the view even if the view is not specifically referenced by the query. The query optimizer considers any and all indexes defined in the database when executing a query, regardless of whether the index was defined on a view or on a base table. If the optimizer estimates that using the indexed view provides the lowest-cost access mechanism, the optimizer chooses the indexed view, similarly to the way it chooses base table indexes even when they are not directly referenced in a query. The optimizer might choose the view when it contains columns that are not referenced by the query, if the view offers the lowest cost option for covering one or more of the columns specified in the query.
When to Use Indexed Views
Because indexed views are more complex to maintain than indexes on base tables, you should use them only when the improved speed in retrieving the results outweighs the increased overhead of data modifications. In other words, indexing views is not a good idea in a high-volume OLTP system. Indexed views work best when the data is relatively static, and you need to process many rows or the view will be referenced by many queries.
When Not to Use Indexed Views
Do not index views without careful consideration. Remember that indexed views work best when the underlying data is infrequently updated, or when a performance penalty for updates is acceptable. Because the structure of an indexed view is more complex than the structure of an index on a base table, the cost of maintaining an indexed view is higher than the cost of maintaining an index on a base table. Do not use indexed views in the following situations:
-
An OLTP (Online Transaction Processing) system with many writes
-
Frequently updated databases
-
Queries that do not involve aggregations or joins
-
Aggregate queries where the result set has almost as many rows as the base table
-
A view with expanding joins in which the result set is larger than the original data stored in the base tables
Requirements for Indexed Views
A view must meet the following requirements before you can create a clustered index on it:
-
Set the ANSI_NULLS option to ON when you create the tables referenced by the view.
-
Set the ANSI_NULLS and QUOTED_IDENTIFIER options to ON prior to creating the view.
-
The view must only reference base tables, not any other views.
-
Base tables referenced by the view must be in the same database as the view and must have the same owner.
-
Create the view and any user-defined functions referenced in the view with the SCHEMABINDING option. This means that the underlying tables or other database objects cannot be altered or dropped as long as the view or function exists. In other words, don't create indexed views until your table design is finalized since you'll just have to drop the view to make schema changes to the table.
-
Reference all table names and user-defined functions with two-part names only—for example, "dbo.Customers" for the Customers table.
-
Any functions used by the view must be deterministic, meaning that the function must always return the same result anytime it's called with the same set of input values.
The following Transact-SQL syntax elements are illegal in an indexed view:
-
The * syntax to specify all columns. Column names must be explicitly stated.
-
Repeated columns—for example, SELECT Col1, Col2, Col1 AS Col. However, you can re-use a column if it's part of a different expression—for example, SELECT Col1, AVG(Col1), Col1 + Col2 AS Total.
-
Derived tables and subqueries.
-
ROWSET.
-
UNION.
-
Outer joins or self joins.
-
TOP and ORDER BY.
-
DISTINCT.
-
COUNT(*). Use COUNT_BIG(*) instead, which returns a bigint data type and is allowed.
-
The following aggregate functions: AVG, MAX, MIN, STDEV, STDEVP, VAR, and VARP.
Indexed Views and Inline Functions
Inline functions can also be used to increase the power and flexibility of indexed views. An indexed view does not support parameters—it stores the complete set of data. However, you can define an inline function with parameters that references the view. Your user-defined function can then apply the parameter values to filter the result set generated by the indexed view. The complex aggregations and joins are done once, at CREATE INDEX time, and all subsequent queries referencing the inline function filter rows from this prebuilt result set.