Foreword
In the database, there are a lot of development rules. Should avoid excessive use of database functions in the database. Excessive use can lead to slow the database, plus database is difficult expanded. Excessive logic in the database, and thereafter the sub-libraries, sub-table more intractable. Of course, for simple applications, without having to have so many rules. The following rules, the rules are mostly in high concurrency environments.
For all applications, the proposed rule
1) database does not store large files, and pictures.
Some people like to store the entire file, base64 pictures in the database, this will only increase the pressure on the database. Generally only storage path, url can be.
2) tables, fields, database with English alphabet.
In the code specification, we recommend the use of English, and even spelling. The use of Chinese is very backward. We must also do so in the database. Chinese, garbled unexpected problems that may occur in the database.
3) Try to replace a subquery Join the way
Because the sub-query result in poor performance. For example, in Mysql, the sub-query is obviously slower than Join, sub-queries need to create a temporary table.
4) Join linked table query using the index as much as possible
Join consuming database query performance too, using the index of conditions can greatly increase query efficiency.
5) can use an index where the use of an index, the index can not be used where the index is not used
Multiple field values for the same, avoid using the index. This did not reach your goal, but increased the pressure on the database. Because it will slow down when you insert data and index space.
Not index the better, it will lead to excessive pressure on the database.
For frequently used as a query, and the repetition rate is not high field, try to use the index, greatly improve query efficiency.
6) Performance Under avoid data type conversion caused stealth
In the table type, inconsistent with the type of query, the query performance will lead to the bottom, even all queries. But some type of query the database are very strict, such as Postgresql.
For example the user table, Cellphone in the database is a string type, the use of select telphone from user where telphone = 0208653266 query
Using proper select telphone from user where telphone = '0208653266'
7) Avoid using the full table scan query error conditions caused by
a. NOT,! =, <>,! <,!>, NOT IN, NOT LIKE, etc., which can cause negative query full table scan
Fuzzy query b.% At the beginning, it will lead to a full table scan
c. Avoid database
8) to avoid number table field values may be null
Table field has a default value, and may not be empty. Doing so may result in a full table scan.
For example select id from t where num is null may be provided on a default value of 0 num, num column of the table to ensure that the value is not null, then this query: select id from t where num = 0
9) When not in use query select * No.
Instead of using a specific inquiry * Number field, rather than select * from t. Because it will consume IO performance of the database, you can not effectively use a covering index.
10) using the function or expression of the properties are not WHERE condition
SELECT id FROM t WHERE from date (day)> = '2019-03-15' cause a full table scan.
The correct wording is: SELECT id FROM t WHERE day> = date ( '2019-03-15 00:00:00')
11) is smaller than the recommended number of fields in a single table 30, a single instance of the data table is less than 500 recommendations
Too many fields, database tables can lead to poor performance, difficult to control and difficult to regulate.
12) Mysql single table data ideally controlled within 5000000
Too much can cause data in mysql table to modify the structure, operating under the query performance, and this threshold is best controlled at 500 million.
For highly concurrent applications, the proposed rule
1) a table, the index number of possible controlled within 3, at most no more than five.
The index is not possible, the more the index database led to greater pressure. Quantity used for bonding index.
2) avoid the use of suitably Join
Sometimes, handling Join deal faster than the database in the program.
3) prohibit the use of foreign keys, foreign key integrity constraints if required application control
Foreign keys will lead between the table and the table coupling, update and delete operations will involve the associated table, very sql performance impact, and even cause a deadlock. High concurrency likely to cause database performance, high concurrency big data business scenarios to use database performance priority.
4) Try not to use growth since the primary key
Since growth is not the primary key because when you insert data, the database will first query the largest index value, and then the insert operation. Therefore, the use of shorter string type or directly into the guid.
5) avoid the use of foreign keys, foreign key integrity constraints if required application control
Foreign keys will lead between the table and the table coupling, update and delete operations will involve the associated table, very sql performance impact, and even cause a deadlock. High concurrency likely to cause database performance, high concurrency big data business scenarios to use database performance priority.
6) Avoid using stored procedures, views, triggers, the Event
Using stored procedures, etc., at high concurrency scenarios, the database is easy CPU is too high and collapsed. Establish the recommended consumption of the mobile terminal of the CPU to the application, to achieve better expansion control purposes.
Follow-up has encountered a problem and suggestions, slowly add other rules ...
No. I can focus on the public, many years of experience of the original article for everyone to share.
