Try to avoid select * from and only return the required fields
When querying table data on a daily basis, I often unconsciously write select * from to query all field information. Although a single table with few records is not interesting, when multiple tables are associated and the table size is large, select * from will return all The fields of the table will affect query efficiency. The better way is to check what is needed and only return the required field information; this is also in line with the least known principle in development and tries not to expose unnecessary information.
Avoid full query and control query granularity as small as possible
In daily development environment queries, you may casually write select * from tableA. Such a query will return all records and all fields. If such a query is accidentally upgraded to the production environment, too slow a query may have disastrous consequences. Full table scan is an inefficient query method and should be avoided as much as possible. Reduce full table scans by using indexes, appropriate filtering conditions, and JOIN optimization. Therefore, when querying, habitually add where condition filtering (such as paging, field filtering, date range, etc.) to return as small data as possible , which will greatly improve query efficiency.
When querying, try to use the index. It is best to design the index in advance.
When there are too many records in a single table, and when table association queries are performed through non-index fields, the query efficiency is very low; at this time, indexing the associated fields will greatly improve the query efficiency. Therefore, when designing a table, it is best to consider the business scenario and establish indexes on fields that are commonly used to filter queries or associate tables, which will be of great benefit to subsequent queries. At the same time, during the query process, try to use index queries, which are much more efficient than non-index queries.
Try to avoid index failure scenarios
Although the index is good, if used improperly, it may not achieve the desired effect. In this case, it is necessary to focus on the failure of the index and try to avoid it .
The main scenarios for index failure include:
- The joint index does not satisfy the leftmost matching principle
- Use select * query
- Using indexed columns for expression operations
- Index columns use built-in functions
- Wrong use of like fuzzy query
- Index column performs type implicit conversion
- Use or operation
- Use >,<,!=, etc. for index column comparisons
- Use is not null
- Use not in and not exixts
- Wrong order by sorting
Avoid full modification when updating and only modify the required fields.
When modifying table records, some simple operations are updateById(Entity entity) . Although the update can be successful, pay attention to SQL and you will find that it has updated all the fields of the Entity , and we may only want to modify a status field. The latter's efficiency of modifying only a small number of fields is obviously higher than that of full modification. More importantly, it can prevent other fields from being accidentally modified , causing other problems.
Try to use numeric values instead of string types
-
Save storage space: Numeric values generally take up less storage space than string types. In large-scale data sets, using numeric types can significantly reduce the storage requirements of the database, thereby improving system performance and efficiency.
-
Improve query performance: When querying the database, comparing numeric types is usually faster than comparing string types. Because numeric types can be compared directly, string types need to be compared character by character.
Choose “hard deletion” of important data carefully
Deleting data is fun, but it can also be risky, especially if you accidentally delete important data. Deleting data usually includes physical deletion (hard deletion) and logical deletion. But no matter what kind of deletion, you must pay attention to the limiting conditions. Don't delete all the data , and don't have to run away.
Physical deletion can save memory space, while ensuring that there is only valid data in the table and has good readability. However, if you physically delete it, the data will most likely not be recovered. Logical deletion, although safer, will pollute the table data to a certain extent. For every subsequent associated query, you have to remember to filter the valid data.
For some valuable historical data, is it possible to consider designing a historical table to transfer deleted historical data ? On the one hand, it can ensure traceability, and at the same time, it can also ensure the simplicity and effectiveness of the original table data.