I like to think of tools bundled with SQL Server as inverted pyramid type, tools for diagnosing and checking general problems at the top, finding and diagnosing problem-specific areas of the tool at the bottom. In addition to providing a convenient way to write SQL scripts, Query Analyzer is the resource you need to use when you need to address specific SQL scripts to clarify the problem. If you need to indicate which query is holding the lock on a particular table, you will also want to use Query Analyzer.
The key diagnostic feature of Query Analyzer is that it can display the execution plan for a query. This execution plan provides you with various types of useful information, such as how and when to use or not to use the index during the execution of a query. It also provides a number of other details, such as sorting, parallelism (parallelism), nested loops, and other things that SQL Server must do when executing a specified query.
Benefits of the program
With Query Analyzer, you can view the projected schedule without running the query itself, or view the real plan after the query executes. It is clear that the real plan will be more accurate because it is physically running queries against the database. However, this approach may not be the best option for systems with large load and/or long-term queries. In a typical case, I run this tool when I think there is a problem with a particular query, or if I expect a query to be called frequently enough in the application to cause performance problems.
You can view the expected execution plan by typing the SQL expression into the query parser and then pressing [ctrl]l]. The execution plan is then displayed in the tab of the results (Results) panel. The execution plan may be difficult to read at first because it is not read from left to right, as in English, but is read from right to left.
In-run plans
Here's an example you can follow, and from this example you can see how to use Query Analyzer to view an execution plan. Consider the following query, which returns the location of an employee and the relevant region from the Northwind database:
SELECT
Territorydescription, RegionDescription
From
Employees E
JOIN employeeterritories et on e.employeeid = Et.employeeid
JOIN territories T on Et.territoryid = T.territoryid
JOIN region R on T.regionid = R.regionid
WHERE
E.employeeid = 1
ORDER by
Territorydescription, RegionDescription
The results of this query show that the number EmployeeID in the East (Eastern) has two regions, a is shown.
Figure A
Query results
http://www.bkjia.com/PHPjc/631122.html www.bkjia.com true http://www.bkjia.com/PHPjc/631122.html techarticle I like to think of tools bundled with SQL Server as inverted pyramid type, tools for diagnosing and checking general problems at the top, finding and diagnosing problem-specific areas of the tool at the bottom. In addition to mentioning ...
