1.explain
Execution format: explain+sql statement
The following will explain each field.
1.1 id
There are three situations:
(1) The id is the same, and the execution order is from top to bottom. Execution sequence 1->3->2.
(2) If it is a subquery, the id sequence number is incremented, and the larger the id, the earlier it will be executed. Execution sequence 3->1->2.
(3) The same id can be regarded as a group, which is executed sequentially from top to bottom. Among all groups, the larger the id, the earlier it will be executed. Execution sequence 3->derived table_>2.
1.2 select_type
Commonly used six values:
simple
A simple select query that does not include subqueries or unions.
primary
If the query contains any complex subparts, the outermost query is marked as primary.
subquery
Subqueries are included in the select or where list.
derived
The subqueries contained in the from list are marked as derived, and mysql will recursively execute these subqueries and put the results in a temporary table.
union
union result
Get the result of the result from the union table.
1.3 table
Show which table the data of this row is about.
1.4 type
8 values will appear. all means full table scan (millions of data must be optimized).
Generally speaking, at least the query is guaranteed to reach the range level, and it is better to reach the ref.
system
const
eq_ref
ref
range
index
all
Full table scan must be optimized when the amount of data is large.
1.5 possible_keys和key
Covering index: The fields used in the query are exactly the same and in the same order as the fields used to build the index.
Such as: select col1, col2 from t1;
create index idx_col1_col2 on t1(col1, col2);
at this time:
1.6 key_len
Generally speaking, the larger key_len is, the more accurate the query result will be.
1.7 ref
1.8 rows
How many rows per table are queried, the smaller the better.
1.9 extra
Contains important information that does not fit in other columns.
Using filesort
It means that the query is not performed in the order in which the indexes are built, and the situation is poor. Optimize as soon as you can.
The second result in the figure below is obviously better than the first one, because there is no using filesort.
Using temporary
With temporary tables, the situation is even worse. Generally common in order by and group by. But it can be optimized by adjusting the number and order of the fields used in the grouping.
In the figure below, the index is a composite index of col1 and col2. The first group by only uses col2, which is poor. The second group by uses col1 and col2, which is optimized.
Using index
2. Index
2.1 Single table optimization case
Initial situation: type is all, and Using filesort appears, the situation is very poor and must be optimized.
Generally speaking, the fields used to build the index are the fields used after the where condition, so it is initially considered to establish a composite index of category_id, comments, and view. The effect is as follows:
using filesort still appears, the situation is poor, delete the original index and re-optimize.
To sum up, we delete comments from the index and only create a composite index of category_id and views. The effect is as follows:
2.2 Two-table optimization case
The left table is book, and the right table is class.
Statements that need to be optimized:
when left join is indexed on the card field of the right table (book):
when left join is indexed on the card field of the left table (class):
since ref is better than index, and the number of query rows is more than the second one, the second one is better.
Conclusion: left join plus right table index, right join plus left table index.
2.3 Three-table optimization case
After explain:
After adding a joint index to the card fields of book and phone:
2.4 Conclusion
Small table drives large table
Prioritize optimization of inner loops
Ensure that the join condition field on the driven table is indexed in the join statement
When it is impossible to guarantee that the join field of the driven table is indexed, do not hesitate to set the joinbuffer
3. Ten examples of index optimization
3.1 Best Left Prefix Rule
First create a joint index of name, age, and pos.
It can be seen from the following that after the joint index is established, only one field query will still use the joint index, which will not cause the index to become invalid.
After the joint index is established, use two fields to query, which will not cause the index to fail:
use all fields to query:
the index creation fields and their order are name, age, pos, the following are age+pos and pos, no index is used:
In summary, if multiple columns are indexed, the query starts from the leftmost front column of the index and does not skip columns in the index.
3.2 Do not perform any operations (calculation, function, type conversion, etc.) on the index column, which will cause the index to fail and turn to full table scan
3.3 Full failure after range
3.4 Try to use the covering index (the index column is consistent with the query column, reduce select *)
3.5 Using unequal (!= or <>) cannot use the index to cause a full table scan
3.6 is null, is not null can not use the index
3.7 like% plus right
Solve the problem that the index is not used when like '%string%'
Use a covering index.
All of these statements in the figure below can use indexes. (The composite index of name and age is established, and the id is automatically indexed as the primary key.)
In the figure below, there are more fields to be queried than the fields to be indexed. The covering index is invalid and the entire table is scanned.
3.8 The index fails if the string is not added with single quotes
The varchar type must be enclosed in single quotes.
The mysql storage engine will perform type conversion at the bottom layer, causing the index to become invalid.
3.9 Less use of or will lead to index failure
The result is correct, but the index will not be used.
4. Database transactions
ACID principles
Atomicity, Consistency, Isolation, Durability.
transaction isolation level
dirty read
One transaction reads uncommitted data from another transaction.
non-repeatable read
A certain row of data in the table is read in a transaction, and the results of multiple reads are different. Mainly for update and delete.
Phantom reading
The data inserted by other transactions is read in one transaction, resulting in inconsistent reading. Mainly for insert.
| isolation level | dirty read | non-repeatable read | Phantom reading |
|---|---|---|---|
| read uncommitted | yes | yes | yes |
| read committed | yes | yes | |
| repeatable read | yes | ||
| Serialization |
mysql default isolation level is repeatable read .
5.MySQL index
