SQL optimization small lecture (1)-do not query redundant columns and rows

SQL column

Summary of SQL basics

SQL advanced knowledge summary

Starting from today, every day will give everyone a little optimization tips. Interested students can follow along to practice a lot, and the sample database can be obtained at the place where you read the original text. The example I used is the backup package of AdventureWorks2012, which can be restored after downloading. Remember that the database can only be restored successfully if it is a higher version. The database I use is SQL Server 2016 version.

1. Do not query redundant columns. In the
process of querying, we often use * to replace all columns in order to save trouble. The advantage is that there is no need to specify the columns. The disadvantage is that the query efficiency of tables with more columns is greatly reduced. E.g:

SELECT * FROM [Sales].[SalesOrderDetail];

When we execute it, we can see the following information:

SQL optimization small lecture (1)-do not query redundant columns and rows

Let me interpret the above related information:

Scan count: the number of index or table scans

Logical read: the number of pages read in the data cache

Physical read: the number of pages read from disk

Read-ahead: The number of pages put into the cache from the disk during the query

lob logical read: read from the data cache, the number of pages of image, text, ntext or large data

Lob physical read: read from disk, the number of pages of image, text, ntext or large data

lob read-ahead: the number of pages of image, text, ntext or large data that are put into the cache from the disk during the query process

The CPU time of the statement is divided into the compilation phase and the execution phase.

CPU time refers to: the time to execute the statement

Occupied time refers to the total time spent reading data from the disk and then processing it

Compilation stage:

SQL Server analysis and compilation time:

Execution phase:

SQL Server execution time:

We will often see this information in the future. This is the most intuitive way to judge a query.

Q: How did the above message interface come out?

A: Click Query-Query Options...-Advanced in the menu bar, just check both SET STATISTICS TIME and SET STATISTICS IO

Let's look up a separate column to see what happens? E.g:

SELECT UnitPrice FROM [Sales].[SalesOrderDetail];

When we execute it, we can see the following information:

SQL optimization small lecture (1)-do not query redundant columns and rows

Through the above time comparison, we can clearly see that the efficiency of listing the column names clearly and not displaying irrelevant columns is greatly improved.

Here is an optimization suggestion that you often see: Do not directly use * to query, but only query the required columns.

2. Do not query redundant rows

  • Use the WHERE keyword in the query to filter out unwanted rows. This is also a way to improve query efficiency. In fact, this is the meaning of the WHERE keyword. E.g:

SELECT UnitPrice FROM [Sales].[SalesOrderDetail] WHERE UnitPrice>1000;

When we execute it, we can see the following information:

SQL optimization small lecture (1)-do not query redundant columns and rows

The time taken up is reduced exponentially, and the effect is obvious.

  • Use the DISTINCT keyword to reduce redundant duplicate rows. E.g:

SELECT DISTINCT UnitPrice FROM [Sales].[SalesOrderDetail] WHERE UnitPrice>1000;

When we execute it, we can see the following information:

SQL optimization small lecture (1)-do not query redundant columns and rows

Some students may have different opinions on the DISTINCT keyword. Later, we will analyze it one by one according to the specific situation.

Today’s lesson will stop here, friends can try it out

Guess you like

Origin blog.51cto.com/15057820/2656457