- Creating and Optimizing Views
- Creating and Modifying Views
- Using Views to Update Data
- Indexed Views
- Optimizing Views and Queries
- Summary
Optimizing Views and Queries
Before getting into the details of optimizing views and queries, consider how SQL Server processes commands that are sent to it.
How SQL Server Processes Commands
When a command is sent to SQL Server for execution, SQL Server performs five steps to execute that command:
-
The command is parsed.
-
The Transact-SQL is standardized. Names are converted into codes that SQL Server can work with internally (such as table names being turned into object IDs, column names into column IDs, and so on).
-
The query is optimized, and an execution plan is generated.
-
The query is compiled.
-
The query is executed.
When you create and save a view or a stored procedure, SQL Server goes through the first two steps only. However, there's a catch where views are concerned. Because you use views as though they were virtual tables, any command that uses a view (SELECT * FROM MyView) has to go through the first two steps a second time, so you really don't gain anything. Nevertheless, there's no real performance hit either, because once SQL Server gets through the first two steps on the command using the view, it can ignore the view itself. Then the command and the view go through optimization, compilation, and execution.
Any command sent to SQL Server benefits from the way SQL Server caches ad hoc statements. If the command is executed a second time in more or less the same form, SQL Server will reuse the cached plan. The performance advantage can be significant if you reuse the same view because the view portion is exactly the same each time.
This is where indexing becomes important—one of the things you can do to improve the performance of your queries, views, and stored procedures is to utilize efficient index design. The SQL Server query optimizer will automatically select the most efficient index for any given query, but that index has to exist in order for it to be used. To get optimal performance out of your queries, you need to create the necessary indexes. However, creating indexes incorrectly can cause worse performance problems than if you had no indexes, so the query optimizer might not use an index if using that index would result in a worse plan than it could achieve otherwise.
Indexing Guidelines
The following are some useful guidelines to observe when you're creating indexes:
-
Create indexes on columns that are used for searching or sorting. Index columns in WHERE and GROUP BY clauses that either return an exact match or have a high proportion of distinct values.
-
Don't create indexes on columns with few unique values. For example, do not create an index on the Country column if the only values it ever contains are the United States, Canada, and Mexico, even though you sort or search by country all the time.
-
Index columns used in joins. In Access, when you create a foreign key, Jet creates a hidden index on the column automatically. SQL Server does not do this, even if you have enforced Declarative Referential Integrity (DRI) by creating a foreign key. In SQL Server, you need to explicitly create indexes on any columns used in joins, unless the values are highly duplicated. Again, don't index Country even though it may be a foreign key if the data only contains a small number of distinct Country values.
-
You can't create indexes on columns defined with the text, ntext, image, or bit data types.
-
Let the Query Analyzer help you out, as discussed in the next section.
Using the Query Analyzer to Tune Performance
Whether your query is implemented in a view or in a stored procedure, using the Query Analyzer's tools can be a big help in optimizing it to run as quickly as possible.
Displaying the Plan
The Query Analyzer's options for helping you understand how a given query is going to execute are all on the Query menu, shown in Figure 9.11. You can display the estimated execution plan for the query, perform index analysis, show the execution plan when the query executes, show a server trace, and show client statistics.
){kind=link}
Figure 9.11
Options available on the Query menu.
The Display Estimated Execution Plan Option
To display the estimated execution plan for a query, highlight the text of the query and press Ctrl+L or select Display Estimated Execution Plan from the Query menu. The execution plan is a graphical display of the data-retrieval methods the SQL Server query optimizer uses. Figure 9.12 shows the estimated execution plan for a query that totals the amount sold by an employee. The icons shown represent the execution of specific statements and queries. If you hover your mouse above each icon, a pop-up box appears listing the statistics for that specific statement. This can alert you to potential problems before you roll out your queries, as shown in Figure 9.12, which displays a warning box that statistics are missing for a table used in the query. The importance of updating statistics will be discussed later in this section.
){kind=link}
Figure
9.12
Displaying the estimated execution plan for a query.
Displaying Index Analysis with the Index Tuning Wizard
In SQL Server 2000, choosing Display Index Analysis from the Query menu runs the Index Tuning Wizard, which analyzes the workload and the database and then recommends an index configuration that will improve the performance of the workload. The introductory dialog box the Index Tuning Wizard displays after launching informs you that it can perform the following tasks:
-
Identify the server and databases to tune
-
Identify the workload to analyze
-
Select the tables to tune
-
Analyze the data and make index recommendations
-
Implement the index recommendations
Note - In SQL Server 7.0, the option in the Query Analyzer for performing index analysis simply analyzes the current query and displays its results and recommendations in the Messages pane. It will also offer to create any indexes it thinks might help.
The next dialog box lets you select a database to work with. If you don't want to analyze all the tables, you can select or deselect them later, but the wizard will only work with one database at a time. There are three additional options, as shown in Figure 9.13. You can elect to keep or drop all existing indexes, perform a thorough analysis, and add indexed views, which are covered earlier in this chapter.
){kind=link}
Figure 9.13
Selecting the database to tune and setting options for the Index Tuning Wizard.
The next wizard dialog box allows you to select a workload from the following three options:
-
My workload file, which is a workload file previously generated with the SQL Server Profiler (see Chapter 15, "Deployment, Tuning, and Maintenance," for information on the SQL Server Profiler).
-
SQL Server table.
-
Query Analyzer selection, which is the default if you launch the Index Tuning Wizard from the Query Analyzer.
You can also use the Advanced Options tab to limit the number of queries that are sampled, to set a limit on the space used for any recommended indexes, and to limit the maximum number of columns per index.
The next wizard dialog box allows you to select the tables to tune, as shown in Figure 9.14.
){kind=link}
Figure
9.14
Selecting the tables to tune.
The following dialog box in the wizard displays recommendations, if any. Running the Index Tuning Wizard on the Northwind database is not very productive because the indexes are already in place.
You can then elect to implement the recommendations on the final wizard dialog box, as shown in Figure 9.15.
){kind=link}
Figure
9.15
Applying the recommended changes.
The final wizard dialog box displays the following information:
-
If you chose to execute now, the database will be updated to the recommended configuration.
-
If you chose to schedule a job, you can view the job in the SQL Server Enterprise Manager.
-
If you chose to save the script to a file, you can view or edit the script with a text editor. (It doesn't say so, but you can also use the Query Analyzer or the Profiler for this editing job.)
The wizard then gives you a piece of good advice: You should back up your database before implementing the recommended configuration. Once you click Finish, the job will be processed (or not, depending on the options you've chosen).
The Show Execution Plan Option
The Show Execution Plan (Ctrl+K) option is different from the Display Estimated Execution Plan option discussed earlier. This option can be toggled on or off. When it's turned on, an additional tab is added to the results pane that displays the execution plan for the query, as shown in Figure 9.16. You won't see anything before the query is executed.
){kind=link}
Figure 9.16
Show Execution Plan adds two tabs to the results pane for the execution plan
and the statistics.
The Show Server Trace Option
The Show Server Trace option, which is new in SQL Server 2000, also adds an additional tab to the results pane to display the trace results, as shown in Figure 9.17. A server trace provides information about the event class, subclass, integer data, text data, database ID, duration, start time, reads and writes, and CPU usage.
){kind=link}
Figure 9.17
Displaying server trace information for a query.
In earlier versions, you had to use the Profiler to see this information. Now it is available right in Query Analyzer.
The Show Client Statistics Option
The Show Client Statistics option is also new in SQL Server 2000. It adds one more tab to the results pane to display statistics, as shown in Figure 9.18.
){kind=link}
Figure
9.18
Displaying client statistics.
Statistics and Indexes
Statistics are very important to the query optimizer—if it does not have good statistical information, it can't make useful recommendations or process queries efficiently. All indexes have distribution statistics that describe the selectivity and distribution of the key values in the index. The selectivity of an index relates to how many rows are identified by each key value. For example, a unique key has high selectivity, whereas a key that is found in many rows has poor selectivity. Fields with a small set of values, like gender for employees, benefit little from indexes, because those indexes will have poor selectivity and will therefore usually be ignored by the optimizer. Distribution statistics measure how the values are spread out among your records. You might have customers in 50 different countries, but if 90% of your customers are in one country, then country isn't a very useful index. The selectivity and distribution statistics are used by SQL Server when processing Transact-SQL statements and are crucial for estimating how efficient an index would be when retrieving data associated with a key value or a range specified in the query. The query optimizer can even compile and use statistics on non-indexed fields. It's very important that your statistics be updated if the composition of your data changes significantly. You can set statistics to be created and updated automatically by going into the Options tab in the Database Properties dialog box, as shown in Figure 9.19.
){kind=link}
Figure
9.19
Setting Auto Create Statistics and Auto Update Statistics in the database's
Properties dialog box.
Updating Statistics (New)
You can update statistics in the Query Analyzer by choosing Tools, Manage Statistics from the menu bar. This will bring up the dialog box shown in Figure 9.20.
){kind=link}
Figure
9.20
The Manage Statistics dialog box lets you update statistics.
Click the New button to create statistics for columns not listed. This will bring up the dialog box where you can create additional statistics, as shown in Figure 9.21.
){kind=link}
Figure
9.21
Creating missing statistics.
Managing Indexes
A new feature in SQL Server 2000 is the way you can use the Query Analyzer to manage indexes without having to use the Enterprise Manager or another tool. Choose Tools, Manage Indexes from the menu bar. This will load the dialog box shown in Figure 9.22. You can create a new index or edit an existing one.
){kind=link}
Figure
9.22
The Manage Indexes dialog box lets you add a new index or edit an existing one.
If you choose the Edit option, you'll get the Edit Existing Index dialog box, as shown in Figure 9.23.
){kind=link}
Figure
9.23
Editing an existing index.
As you can see, the Query Analyzer offers a powerful set of tools for tuning and optimizing your queries. Performance tuning is also covered in Chapter 15.