Five Ways to Improve SQL server performance

Sometimes, in order to make the application Program It runs faster, and all the work is to make small adjustments here or there. Ah, but the key is to determine how to adjust it! Sooner or later, you will encounter this situation: the SQL query in the application cannot respond as you want. It either does not return data or takes a surprising amount of time. If it reduces the speed of reporting or your enterprise applications, users will not be satisfied if they have to wait too long. Just as your parents don't want to explain why they came back in the middle of the night, they won't explain why the query took so long. ("Sorry, Mom, I have used too many left join statements .") Users want their applications to respond quickly and their reports can return analysis data instantly. As far as I am concerned, if it takes more than 10 seconds to load a page when surfing the web (well, five seconds is more practical), I will also be impatient.

To solve these problems, it is important to find the root cause of the problem. So where should we start? The root cause is generally the database design and access to its query. In this month's column, I will talk about four technologies that can be used to improve the performance of SQL Server? Or improve the scalability of the application. I will carefully describe the use of left join and cross join and the retrieval of identity values. Remember, there is no magic solution at all. Adjusting your database and its query takes time and analysis, and requires a lot of tests. These technologies have proven to be effective, but some of them may be more suitable for your applications than others.

Return identity from insert

I decided to start with a lot of problems: how to retrieve the identity value after executing SQL insert. Generally, the question is not how to write a query value, but where and when to search. In SQL Server, the following statement can be used to retrieve the identity value created by the latest SQL statement running on the active database connection:

Select @ identity

This SQL statement is not complex, but it should be remembered that if the latest SQL statement is not insert, or you have run this SQL statement for other connections other than insert SQL, the expected value is not obtained. You must run the followingCodeTo retrieve the identity that follows the insert SQL statement and is located on the same connection, as shown below:

Insert into products (productname) values ('chalk ')

Select @ identity

Running These queries for the northwind database on a connection will return the identity value of a new product named chalk. Therefore, when using Visual Basic of ADO? In the application, you can run the following statement:

Set ors = OCN. Execute ("set nocount on; insert into products _

(Productname) values ('chalk '); select @ identity ")

Lproductid = Ors (0)

This code tells SQL Server not to return the row count of the query, then execute the insert statement, and return the identity value created for the new row. The Set nocount on statement indicates that the returned record set contains one row and one column, which contains the new identity value. If this statement is not available, an empty record set is first returned (because the insert statement does not return any data), then the second record set is returned, and the second record set contains the identity value. This may be confusing, especially because you never expected insert to return a record set. This happens because SQL Server sees this row count (that is, one row is affected) and interprets it as a record set. Therefore, the real data is pushed back to the second record set. Of course, you can use the nextrecordset method in ADO to obtain the second record set. However, if you can always return the record set first and only return the record set, it is more convenient and efficient.

This method is valid, but additional code needs to be added to the SQL statement. Another way to get the same result is to use the set nocount on statement before insert, and place the select @ identity statement in the for insert trigger in the table, as shown in the following code snippet. In this way, any insert statement entering the table will automatically return the identity value.

Create trigger trproducts_insert on products for insert

Select @ identity

Go

The trigger is started only when insert is performed on the products table. Therefore, it always returns an identity after successful insert. With this technology, you can always retrieve the identity value in the application in the same way.

Embedded view and temporary table

In some cases, you need to connect data to other data that can only be collected by executing group by and then Executing standard query. For example, to query the information about the latest five orders, you must first know which orders are used. This can be searched using the SQL query that returns the order ID. This data is stored in a temporary table (this is a common technology) and then joined with the products table to return the number of products sold in these orders:

Create Table # temp1 (orderid int not null ,_

Orderdate datetime not null)

Insert into # temp1 (orderid, orderdate)

Select top 5 O. orderid, O. orderdate

From orders o order by O. orderdate DESC

Select P. productname, sum (OD. Quantity) as productquantity

From # temp1 t

Inner join [Order Details] OD on T. orderid = OD. orderid

Inner join products P On OD. productid = P. productid

Group by P. productname

Order by P. productname

Drop table # temp1

These SQL statements create a temporary table, insert data into the table, join other data with the table, and then remove the temporary table. This results in a large number of I/O operations on this query. Therefore, you can rewrite the query and replace the temporary table with an embedded view. The nested view is just a query that can be joined to the from clause. Therefore, you do not need to spend a lot of I/O and disk access on temporary tables in tempdb, but you can use the embedded view to get the same result:

Select P. productname,

Sum (OD. Quantity) as productquantity

From (

Select top 5 O. orderid, O. orderdate

From orders o

Order by O. orderdate DESC

) T

Inner join [Order Details] OD on T. orderid = OD. orderid

Inner join products P On OD. productid = P. productid

Group

P. productname

Order

P. productname

This query is not only more efficient than the previous query, but also shorter in length. Temporary tables consume a large amount of resources. If you only need to connect data to other queries, you can try using the embedded view to save resources.
Avoid left join and null

Of course, you often need to execute left join and use null values. However, they do not apply to all situations. Changing the construction method of SQL queries may result in shortening a report that takes a few minutes to only a few seconds. Sometimes, you must adjust the data format in the query to adapt to the display method required by the application. Although the table data type reduces resource usage, many areas can be optimized in the query. A valuable common function of SQL is left join. It can be used to retrieve all rows in the first table, all matched rows in the second table, and all rows in the second table that do not match the first table. For example, if you want to return each customer and their orders, use left join to display customers with and without orders.

This tool may be excessively used. Left join consumes a lot of resources because it contains data that matches null (nonexistent) data. In some cases, this is inevitable, but the cost may be very high. Left join consumes more resources than inner join, so if you can rewrite the query so that the query does not use any left join, you will get a considerable return.

One technique that accelerates query using left join involves creating a table data type and inserting all rows in the first table (the table on the left of left join, then, use the value in the second table to update the table data type. This technology is a two-step process, but it can save a lot of time compared with the standard left join. A good rule is to try different technologies and record the time required for each technology until you get the best query for the execution performance of your application.

When testing the query speed, it is necessary to run the query multiple times and then take an average value. Because queries (or stored procedures) may be stored in the SQL server memory process cache, the first attempt may take a little longer, and all subsequent attempts will take a short time. In addition, you may be running other queries for the same table when running your query. When other queries lock and unlock these tables, your queries may have to wait in queue. For example, if someone is updating the data in this table when you perform a query, your query may take longer to execute during update submission.

The simplest way to avoid speed reduction when left join is to design databases around them as much as possible. For example, assume that a product may have a category or no category. If the products table stores the category ID instead of the category of a specific product, you can store the null value in the field. Then you must execute left join to obtain all products and their categories. You can create a category with a value of "no category" to specify that the foreign key relationship does not allow null values. By performing the preceding operations, you can use inner join to retrieve all products and their categories. Although this seems to be a work und with excess data, it may be a very valuable technology because it can eliminate left join statements that consume more resources in SQL batch processing statements. Using this concept in databases can save a lot of processing time. Remember, even a few seconds is important for your users, because when many users are accessing the same online database application, the seconds actually mean a lot.

Flexible Use of cartesian products

I will give a very detailed introduction to this technique and advocate the use of cartesian products in some cases. For some reason, cross join has been condemned and developers are often warned not to use them at all. In many cases, they consume too many resources and thus cannot be used efficiently. However, like any tool in SQL, they will be very valuable if used correctly. For example, if you want to run a query that returns monthly data (even if a customer has no orders for a specific month), you can easily use the Cartesian product.

Although this does not seem magical, consider if you perform standard inner join from the customer to the order (these orders are grouped by month and sales are subtotal, only the month in which the customer has an order is obtained. Therefore, you will not receive a value of 0 for the month when the customer has not subscribed to any product. If you want to draw a chart for each customer to show monthly and monthly sales, you may want this chart to include months with monthly sales of 0 to visually identify these months. If you use the SQL statement in figure 2 (last page), the data skips the month with a sales volume of $0, because in the order table, zero sales does not contain any rows (assuming you only store the events that occur ).

Although the Code in Figure 3 (the last page) is long, it can achieve the goal of getting all sales data (or even months without sales. First, it extracts the list of all last year's months and puts them into the first table data type table (@ tblmonths. Next, this code retrieves the names of all customer companies that have sales within this period of time, and then puts them into another table data type table (@ tblcus-tomers. These two tables store all the basic data necessary to create a result set, except for the actual sales volume. The first table lists all months (12 rows), and the second table lists all customers with sales during this period (81 for me ). Not every customer has purchased the product every month in the past 12 months. Therefore, executing inner join or left join will not return each customer every month. These operations only return the customer and month of the purchased product.

The Cartesian product returns all customers of all months. Descartes multiply the first table and the second table to generate a row set, which contains the result of multiplying the number of rows in the first table and the number of rows in the second table. Therefore, the Cartesian Product Returns 972 rows to the Table @ tblfinal. The final step is to update the @ tblfinal table and select the final row set using the total monthly sales of each customer within this date range.

Cross join can be used with caution if there are many resources occupied by the Cartesian product without the real Cartesian product. For example, if cross join is performed on products and categories, and most rows are filtered using the WHERE clause, distinct, or group by clause, the same result is obtained using inner join, and the efficiency is much higher. If you need to return data for all possibilities (for example, when you want to fill a chart with the monthly sales date), the Cartesian product may be very helpful. However, you should not use them for other purposes, because inner join is much more efficient in most scenarios.
Zero missing
Here we will introduce other common technologies that can help improve SQL query efficiency. Assume that you group all sales people by region and subtotal their sales, but you only want those databases to be marked as active sales people. You can group sales people by region and use the having clause to remove those who are not in the active status. You can also perform this operation in the WHERE clause. Executing this operation in the WHERE clause reduces the number of rows to be grouped, which is more efficient than executing this operation in the having clause. Row-Based Filtering in the having clause forces queries to group data that will be removed in the WHERE clause.

Another way to improve efficiency is to use the distinct keyword to search for separate reports of data rows instead of using the group by clause. In this case, SQL statements using the distinct keyword are more efficient. Use group by when you need to calculate Aggregate functions (sum, Count, Max, etc. In addition, if your query always returns a unique row, do not use the distinct keyword. In this case, the distinct keyword only increases the system overhead.

As you can see, there are a lot of technologies that can be used to optimize queries and implement specific business rules. The trick is to try and compare their performance. The most important thing is testing, testing, and re-testing. In the future sections of this column, I will continue to describe the concept of SQL Server in depth, including database design, good indexing practices, and SQL Server Security examples.