Specification summary

Index specification

默认添加的索引都是BTree索引。Innodb只支持BTree索引。

设计索引原则

- 最适合索引的列是WHERE子句中的列，而不是SELECT中的列。
- 如果索引的字段很长，使用前缀索引
- 删除不常用索引
- 建议单表不超过5个

Single-table index is not more than 5 [index can improve query performance, but will reduce the efficiency of plug updated]
Each Innodb table must have a primary key, the master key [recommend] ID value increment
Recommended index column
- Appear in the WHERE clause of SELECT, UPDATE, DELETE statements in the column
- It contains fields in the ORDER BY, GROUP BY, DISTINCT in
- Does not want to meet the column fields 1 and 2 have established an index, usually the better to establish a joint index fields 1 and 2
- Multi-table join the association columns
Avoid creating redundant indexes and index repeat
- Example duplicate index: primary key (id), index (id), unique index (id)
- Example redundancy index: index (a, b, c), index (a, b), index (a)
Covering index

to be continue
Foreign key constraint offs

Development of norms

Prohibit the use of SELECT * You must use SELECT <field list> query
Instead of a join operation subqueries
Using the associated table join is preferably not more than 5
When the judgment corresponding to the same column or used in place of or in
Prohibit the use of order by rand () random sequencing

[Recommend obtaining a random value in the program, and how the data is acquired from the database. ]
WHERE clause prohibited functions to convert the column and calculated

[Lead to unusable index when the column is a function of conversion or calculation]
Use UNION ALL when obviously there will be no repeat value instead of UNION
- All data to be re-UNION will operate two result sets into a temporary table and then
- UNION ALL no longer the result set to retry
Split large complex SQL into several small SQL
- Large SQL logic is more complex, CPU-intensive calculation of SQL
- MySQL, a SQL can only be calculated using a CPU
- After the SQL resolution can be performed in parallel to improve the processing efficiency by

Index design specifications

1. Limit the number of indexes on each table, a single table indexes do not recommend more than five

The index is not better! Indexes can improve the efficiency can also reduce efficiency.

Indexes can increase query efficiency, but will also reduce the efficiency of insert and update, and even in some cases will reduce the query efficiency.

Because MySQL optimizer when choosing how to optimize queries, based unified messaging, each index can be used to evaluate, to generate a best execution plan , if there are multiple indexes at the same time can be used to query, MySQL will increase the time optimizer generates the execution plan, it will also reduce query performance.

2. Each Innodb table must have a primary key

Innodb is an index organized tables: logical order and the order index stored data is the same. Each table may have multiple indexes, the storage order of the table there is only one.

Innodb is in the order of the primary key index organized tables

Do not use frequently updated column as the primary key is not applicable to multi-column primary key (equivalent to the joint index)
Do not use UUID, MD5, HASH, string column as the primary key (data not guarantee the order of growth)
[Recommended for the primary key value increment ID]

Common recommendations index column

Appear in the WHERE clause of SELECT, UPDATE, DELETE statements in the column
It contains fields in the ORDER BY, GROUP BY, DISTINCT in
Does not want to meet the column fields 1 and 2 have established an index, usually the better to establish a joint index fields 1 and 2
Multi-table join the association columns

Avoid creating redundancy and duplication index index (increase the time of the query optimizer generates an execution plan)

Example duplicate index: primary key (id), index (id), unique index (id)
Example redundancy index: index (a, b, c), index (a, b), index (a)

For frequent queries priority to use a covering index

A covering index: that contains all the query fields (where, select, ordery by, group by field included) index

Covering index benefits:

Innodb avoid secondary query table indexed: Innodb aggregated in a sequential index to store, for Innodb, the two indexes stored in the leaf node is the primary key information line, if the secondary index is a query data then, after finding the appropriate key, we have to get real data needed to conduct the second query by the primary key. In the cover index, the two key values of the index may be acquired all the data, avoiding a secondary key for the primary query, reducing IO operations, improve search efficiency.
Random IO can accelerate query efficiency into order IO: since the covering index is stored in order of the key values, for a range lookup for intensive IO, IO comparative random access data of each line to be much less from the disk, so IO use covering index during the random access can read the disk into the order of the index to find the IO.

6. SET index specification

Avoid using foreign key constraints

We do not recommend the use of foreign key constraints (foreign key), but it must be indexed on the associated bond between the table and the table
Foreign key reference used to ensure data integrity, it is recommended to achieve the business end of the
Foreign keys will affect the parent and child tables write operation decreases the performance of

Database SQL development specification

Prohibit the use of SELECT * You must use SELECT <field list> query

the reason:

Consume more CPU and IO resources to network bandwidth
You can not use a covering index
You can reduce the impact of the change table structure

Avoid using sub-queries, you can handle the query optimizer to join operations

Normally in sub-clause in the query, and the subquery is a simple SQL (does not include union, group by, order by, limit clause), it can be converted to handle inquiries related query optimization.

Subquery causes of poor performance:

Sub-query result set can not use an index, usually sub-query result set is stored in a temporary table, whether temporary table or disk memory temporary tables will not exist indexes, query performance will be affected to some degree. Especially for the return result sets relatively large sub-queries, the greater its impact on query performance.

Since the sub-query will produce a lot of temporary table has no index, it will consume excessive CPU and IO resources, resulting in a large number of slow queries.

Avoid using too much JOIN association table

For MySQL, is the presence of associative cache, the cache size may be set by the parameter join_buffer_size.

In MySQL, SQL and more for the same association (join) a table, it will allocate a multi-associative cache, SQL, if in a more associated table, the greater the amount of memory.

If the program is in a lot of use associated with the operation of multi-table, while in the case of unreasonable join_buffer_size set, it is easy to cause the server memory overflow, it will affect the stability of the server database performance.

At the same time for the association operation, the operation will produce a temporary table, affecting the efficiency of queries, MySQL allows up to 61 associated table, recommends no more than five.

When the judgment corresponding to the same column or used in place of or in

in the value of not more than 500, in operation more efficient use of the index, or in most cases rarely make use of the index.

Prohibit the use of order by rand () random sequencing

order by rand () will list all qualifying data loaded into memory, and then sorted according to the randomly generated value for all data in memory, and each row may have a randomly generated value, if the condition of data set is very large, it will consume large amounts of CPU and IO and memory resources.

Recommend obtaining a random value in the program, and how the data is acquired from the database.

WHERE clause prohibited functions to convert the column and calculated

It will cause the index can not be used when the column is a function of conversion or calculation

Not recommended:

where date(create_time)='20190101'

recommend:

where create_time >= '20190101' and create_time < '20190102'

Use UNION ALL when obviously there will be no repeat value instead of UNION

All data to be re-UNION will operate two result sets into a temporary table and then
UNION ALL no longer the result set to retry

Split large complex SQL into several small SQL

Large SQL logic is more complex, CPU-intensive calculation of SQL
MySQL, a SQL can only be calculated using a CPU
After the SQL resolution can be performed in parallel to improve the processing efficiency by

Reference material

A very complete specification MySQL

https://baijiahao.baidu.com/s?id=1622786252178335118&wfr=spider&for=pc

MySQL index && development specifications