Database SQL optimization that beginners can do

For a developer who is just getting started, don't talk about frameworks and architectures all day long, and lay a solid foundation first. In the process of study and work, pay attention to your own summary and accumulation, develop good programming habits, and pay attention to the details in the development process. Often in the actual development process, due to the lack of details and rigor, it may lead to catastrophic consequences.
Today, I will sort out some details that should be paid attention to in developing SQL programming based on relational databases. These details are not very difficult, but more emphasis is that a developer must have a rigorous and good programming habit. Figure convenient and easy to take shortcuts.

1. General principles
If the project team has developed very detailed and clear specifications, you have to abandon your previous set of specifications and unconditionally follow the internal development specifications, unless your proposal changes the specifications of your project team. These specifications include code naming, comments, formats, logs, exceptions, directory structure levels, sql writing and other conventions in programming.
Regarding optimization, in view of the actual problems in the project, it must be measured in combination with the actual project environment for actual test comparisons, flexible control, and direct optimization effects are better than all talk on paper.

2. Examples of details
1. Keep a clear mind and write statements for tables with large amounts of data, and then combine them with actual test comparisons, not only focusing on results but also focusing on efficiency (general principle).

2. If you can use where to filter out large amounts of data first, filter out large data sets first (big principle).

3. To reduce the design of constraints, try to hand over all constraints to the service layer for the code to control, so as to reduce the pressure on the database server (big principle).

4. Do not come to Cartesian product unless necessary, it is too violent and terrifying.

5. When the built-in function can be used preferentially in sql query, try to use the built-in function that comes with the database first. I believe that the internal packaging of the product is definitely better than its own packaging.

6. Try to avoid * query all in the select query statement, and take as many fields as needed according to the actual business needs.
Example: If a table has 60 fields, and only two of them are needed, if you use * to get all the queries on database columns or the overhead of data transmission, it is a waste of time and resources.

7. Minimize the connection to the database on the basis of meeting the business data. After each connection to the database, the retrieval of resources such as statement execution plans, indexes, and constraints in the database is very resource-intensive, and it can be done one at a time. The sql statement can be done as much as possible at one time.

8. The location of the where clause is located. In a SQL parsing sequence, the where is executed after the multi-table connection. If the condition of the where clause can filter out the large amount of data in advance, the where clause can be advanced before the connection occurs.

9. When querying the connection table, select the appropriate basic table for connection in combination with the business.

10. In the having statement of group by, try to use the where statement to filter out first. The having statement is filtered on the basis of the result of group by. If where can give priority to the data filtering efficiency will be improved.

11. Index
Index is a powerful tool to improve query, but it is also a double-edged sword. If you don’t use it properly, you can kill yourself in seconds. Therefore, you must know the basic principles of indexing, what scenarios are suitable for use, and how to write sql. Hit it and list the occasions when the index will not be hit:
some systems have undergone secondary development, third development, and may have undergone multiple changes in the intermediate business. The replacement of developers has led to many indexes that are no longer useful. , be sure to monitor the database to check the index usage. If you find an unused index, you must clean up and optimize it;
add is null or is not null
to the index column ; Will hit, such as to_char, to_number operation functions;
Implicit conversion will also cause the index to fail, such as id=100, if the id is a character type, it will be converted to to_number(id)=5, so do not write numbers in character format, and do not write characters in numeric format;
!= , not, <> may cause the index to fail;
someone often uses 1=1 in paging to cause the index to fail;
fuzzy matching like will cause the index to not be hit %hello will not be hit, hello% will be hit;
operator The + and || splices disable the index;

12. Minimize distinct, union, and order by operations, because this type of operation requires sorting data in the database, which consumes resources.

13. The efficiency of union all is higher than that of union. If it is clear that there is no duplicate data, please use union all, because union will take the initiative to deduplicate.

14. Reduce the use of or and in keywords, and replace the use of or or in with exist or union.

15. The use of stored procedures Whether the
stored procedures are used or not depends entirely on the project specification and the project environment to make comprehensive decisions. This is a degree of certainty. Whether to intercept the business processing in the upper service layer or put it on the database server There are pros and cons to a comprehensive approach.

16. Low-level errors: Use native JDBC without closing resources, and try to perform transaction commit or rollback operations to release database server memory resources.