MySQL high concurrency optimization

Ensure that the number of accesses to the database is minimized on the basis of the realization of the function (the query results can be saved in the cache to reduce the number of queries); through the search parameters, the number of rows accessed to the table and the result set are minimized, thereby reducing the network burden ; The operations that can be separated should be handled separately as much as possible to improve the response speed each time; when using SQL in the data window, try to put the used index in the first column of the selection; the structure of the algorithm should be as simple as possible; when querying, do not use too much Wildcards such as SELECT * FROM T1 statement, select a few columns to use, such as: SELECTCOL1,COL2 FROM T1; try to limit the number of result set rows as much as possible, such as: SELECT TOP 300 COL1,COL2,COL3 FROM T1, Because in some cases users do not need so much data.

1. Try to avoid the null value judgment of the field in the where clause, otherwise the engine will give up the use of the index and perform a full table scan, such as:
select id from t where num is null

You can set the default value of 0 on num to ensure that There is no null value in the num column of the table, and then query like this:
select id from t where num=0

2. Try to avoid using the != or <> operator in the where clause, otherwise the engine will give up the use of the index and perform a full table scan . The optimizer will not be able to determine the number of rows that will be hit by the index, so it needs to search all the rows of the table.

3. Try to avoid using or to join conditions in the where clause, otherwise the engine will give up using the index and perform a full table scan, such as:
select id from t where num=10 or num=20
You can query like this:
select id from t where num=10
union all
select id from t where num=20
4.in and not in should also be used with caution, because IN will make the system unable to use the index, but can only directly search the data in the table. For example:
select id from t where num in(1,2,3)

For continuous values, if you can use between, do not use in:
select id from t where num between 1 and 3

5. Try to avoid indexed character data , use a non-initial search. This also makes it impossible for the engine to take advantage of the index.
See the following example:
SELECT * FROM T1 WHERE NAME LIKE '%L%'
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)='L'
SELECT * FROM T1 WHERE NAME LIKE 'L%'
even if the NAME field is indexed , the first two queries still cannot use the index to complete the accelerated operation, and the engine has to operate all the data in the whole table one by one to complete the task. And the third query can use the index to speed up the operation.

6. Force the query optimizer to use an index if necessary, such as using a parameter in the where clause, which also results in a full table scan. Because SQL resolves local variables only at runtime, the optimizer cannot defer the choice of an access plan to runtime; it must choose it at compile time. However, if the access plan is built at compile time, the value of the variable is unknown and cannot be used as an input for index selection. For example, the following statement will perform a full table scan:

select id from t where num=@num

can be changed to force the query to use the index:
select id from t with(index(index name)) where num=@num

7. Try to avoid expression operations on fields in the where clause, which will cause the engine to give up using the index and perform a full table scan. For example:

SELECT * FROM T1 WHERE F1/2=100

should be changed to:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)='5378'
should be changed to:
SELECT * FROM RECORD WHERE CARD_NO LIKE '5378%'
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
should be changed to:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth i.e. any operation on the column All will result in table scan, which includes database functions, calculation expressions, etc. When querying, move the operation to the right of the equal sign as much as possible.

8. You should try to avoid functional operations on fields in the where clause, which will cause the engine to give up the use of indexes and perform full table scans. Such as:
select id from t where substring(name,1,3)='abc'--name id starting with abc
select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30' The generated id
should be changed to:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9. Do not perform functions, arithmetic operations or other expression operations on the left side of "=" in the where clause, otherwise the system will Indexes may not be used correctly.

10. When using an index field as a condition, if the index is a composite index, the first field in the index must be used as a condition to ensure that the system uses the index, otherwise the index will not be used and should be As much as possible, make the field order consistent with the index order.

11. Many times using exists is a good choice:
elect num from a where num in(select num from b)
Replace with the following statement:
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
both produce the same result, but the latter is obviously more efficient than the former. Because the latter does not generate a lot of locking table scans or index scans.

If you want to check whether a certain record exists in the table, don't use count(*), which is inefficient and wastes server resources. Can be replaced with EXISTS. For example:
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')

can be written as:

IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
It is often necessary to write a T_SQL statement to compare a parent result set with a child result set, To find out whether there are records in the parent result set but not in the child result set, such as:
SELECT a.hdr_key FROM hdr_tbl a---- tbl a means tbl Replace
WHERE NOT EXISTS with alias a (SELECT * FROM dtl_tbl b WHERE a .hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
12. Try to use table variables instead of temporary tables. If the table variable contains a lot of data, be aware that the indexes are very limited (only the primary key index).

13. Avoid frequent creation and deletion of temporary tables to reduce the consumption of system table resources.

14. Temporary tables are not unusable, and their proper use can make certain routines more efficient, for example, when a large table or a dataset in a frequently used table needs to be repeatedly referenced. However, for one-time events, it is better to use an export table.

15. When creating a new temporary table, if a large amount of data is inserted at one time, you can use select into instead of create table to avoid causing a large number of logs to improve the speed; if the amount of data is not large, in order to alleviate the resources of the system table, you should first create table, then insert.

16. If temporary tables are used, all temporary tables must be explicitly deleted at the end of the stored procedure, first truncate table, and then drop table, which can avoid long-time locking of system tables.

17. Set SET NOCOUNT ON at the beginning of all stored procedures and triggers, and set SET NOCOUNT OFF at the end. There is no need to send a DONE_IN_PROC message to the client after each statement of stored procedures and triggers is executed.

18. Try to avoid large transaction operations to improve system concurrency.

19. Try to avoid returning a large amount of data to the client. If the amount of data is too large, you should consider whether the corresponding demand is reasonable.

20. Avoid using incompatible data types. For example, float and int, char and varchar, binary and varbinary are incompatible (conditional judgment). Data type incompatibilities may prevent the optimizer from performing some optimizations that it could otherwise. Example:
SELECT name FROM employee WHERE salary > 60000
In this statement, if the salary field is of type money, it is difficult for the optimizer to optimize it, because 60000 is an integer number. We should convert integers to coins at program time, not at runtime.

21. Make full use of the join condition (the more conditions, the faster). In some cases, there may be more than one join condition between the two tables. In this case, writing the join condition completely in the WHERE clause may greatly increase the number of join conditions. Improve query speed.

Example:
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO

SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B .ACCOUNT_NO
The second sentence will execute much faster than the first.