Tuning SQL Server Scripts Using Query Analyzer_PHP Tutorial

I like to think of the tools bundled with SQL Server as an inverted pyramid, with tools for diagnosing and checking general problems at the top, and tools for finding and diagnosing specific areas of problems at the bottom. In addition to providing a convenient way to write SQL scripts, the Query Analyzer is a resource you need to use when you need to solve a specific problem in a specific SQL script. You'll also want to use Query Analyzer if you need to figure out which query is holding a lock on a particular table.
The key diagnostic feature of Query Analyzer is its ability to display the execution plan of a query. This execution plan will provide you with various types of useful information, such as how and when to use or not use indexes during the execution of the query. It also provides many other details, such as sorting, parallelism, nested loops, and other things that the SQL server must do to execute the specified query.
　
Benefits of Plans
With Query Analyzer, you can view projected plans without running the query itself, or view the actual plan after the query has been executed. Obviously, the real plan will be more accurate because it physically runs the query against the database. But for queries with heavy system loads and/or long-term queries, this approach may not be the best choice. Typically, I run this when I think there is a problem with a particular query, or if I anticipate that a query will be called frequently enough in the application that it might cause performance issues. tool.
You can view the expected execution plan by entering the SQL expression into Query Analyzer and pressing [Ctrl]L. The execution plan is then displayed in the Results panel tab. The execution plan may be difficult to read at first because it is not read from left to right like English, but from right to left.
Running Plan
Here is an example you can follow, from this example you can see how to use Query Analyzer to view an execution plan. Consider the following query, which returns the location and associated region of an employee 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 EmployeeId No. 1 has two regions in the East, as shown in Figure A.

Figure A

Query results

http://www.bkjia.com/PHPjc/631128.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/631128.htmlTechArticleI like to think of the tools bundled with SQL Server as an inverted pyramid, tools for diagnosing and checking general problems At the top, tools for finding and diagnosing specific areas of problem are at the bottom. In addition to mentioning...