The mysql video tutorial column introduces the life cycle of relational database sql.
The execution process of MYSQL Query Processing sql is basically the same as the mysql architecture
Implementation process:
Connector:
Establish a connection with MySQL for querying SQL statements and determining permissions.
Query cache:
If the statement is not in the query cache, it will continue to the subsequent execution stage. After the execution is completed, the execution results will be stored in the query cache.
If the query hits the cache, MySQL does not need to perform the following complex operations, and can directly return the results to improve efficiency.
Analyzer:
For hard analysis of SQL statements, the analyzer will do it first lexical analysis. Analyze the composition of SQL statements. Determine whether the input SQL statement meets the grammatical rules.
Optimizer: The
optimizer decides which index to use when there are multiple indexes in a table; or when a statement has multiple table associations (join), it decides the connection order of each table. The logical results of different execution methods are the same, but the execution efficiency will be different, and the role of the optimizer is to decide which scheme to use.
Actuator:
Indexed: The interface is called for the first row that meets the condition for the first time, and then the interface is looped to get the next row that meets the condition, and finally the query result is returned to the client.
No index: Call the InnoDB engine interface to get this table The first line of, judge the sql query condition, if it is not, skip it, if it is, save this line in the result set; call the engine interface to fetch the next line, repeat the same judgment logic until the last line of this table is fetched. The executor returns the record set composed of all the rows that meet the conditions in the above traversal process as a result set to the client.
Understand the execution plan. The
EXPLAIN command outputs how MySQL will execute your SQL statement, but it will not return data.
how to use
[root@localhost][(none)]> explain select * from 表名 where project_id = 36;
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+
| 1 | SIMPLE | 表名 | NULL | ref | project_id | project_id | 4 | const | 797964 | 100.00 | NULL |
+----+-------------+--------------------------+------------+------+---------------+------------+---------+-------+--------+----------+-------+复制代码
The id
id is the same. The execution order is
different from top to bottom . The larger the id value, the higher the priority, the earlier it will be executed
select_type
SIMPLE: simple select query, the query does not contain sub-queries or union
PRIMARY: the query contains sub-parts, the most The outer query is marked as primary
DERIVED: is part of the subquery from
DEPENDENT SUBQUERY: the first SELECT in the subquery, the subquery depends on the result of the outer query
SUBQUERY means that the subquery is included in the select or where list.
MATERIALIZED: Represents the subquery of the in condition after where
UNION: Represents the second or subsequent select statement in the
union UNION RESULT: The result
table
object of the union
type
system> const> eq_ref> ref> range> index> ALL (query efficiency )
system: There is only one piece of data in the table. This type is a special const type.
const: For the equivalent query scan of the primary key or unique index, only one row of data is returned at most. The speed is very fast because it only needs to be read once.
eq_ref: This type usually appears in multi-table join queries, which means that each result of the previous table can only match one row of the result of the latter table, and the comparison operation of the query is usually =, the query efficiency is higher
ref: this type Usually appear in multi-table join queries, for non-unique or non-primary key indexes, or query
ranges that use the leftmost prefix rule index : Range scans usually appear in <>, >, >=, <, <= , IS NULL, <=>, BETWEEN, IN() operation
index: index tree scan
ALL: full table scan (full table scan)
possible_keys
may use the index, note that the
query may not be used if there is an index on the field involved , The index will be listed.
When the column is NULL, it is necessary to consider whether the current SQL needs to be optimized. The
key
shows the indexes actually used by MySQL in the query. If the index is not used, NULL is displayed.
If a covering index is used in the query (covering index: the data of the index covers all the data that needs to be queried), the index only appears in the key list. The
key_length
index length
ref
indicates the connection matching condition of the above table, that is, which columns or constants are Used to find the value on the index column
rows
returns the estimated result set number, not an accurate value
filtered
Shows the number of returned results as a percentage of the number of rows that need to be read. The larger the filtered value, the better.
Extra
Using where: indicates that the optimizer needs to return to the table through the index, and then filters the query data at the server layer.
Using index: indicates that the index is directly accessed Enough to obtain the required data, no need to return to the table.
Using index condition: a new feature added after version 5.6 (Index Condition Pushdown).
Using index for group-by: using an index for GROUP BY or DISTINCT queries.
Using filesort: When there is Using filesort in Extra, it means that MySQL requires additional sorting operations, and the sorting effect cannot be achieved by index order. Generally, there is Using filesort, which is recommended to be optimized and removed, because such queries consume large CPU resources.
Using temporary temporary tables are used. Often appears in the case of GROUP BY and ORDER BY clauses. (
Sort buffer or disk is used) Just looking at the literal meaning of filesort, you might think that you want to use disk files for sorting, but it's not entirely true. When MySQL cannot use the index for sorting, it will use its own sorting algorithm (quick sorting algorithm) to sort the data in the memory (sort buffer). If the memory cannot be loaded, it will divide the data on the disk into blocks, and then Sort each data block, and then merge each block into an ordered result set (in fact, the outer sort).
When sorting the join operation, if the ORDER BY only refers to the columns of the first table, MySQL performs a filesort operation on the table, and then performs the join processing. At this time, EXPLAIN outputs "Using filesort"; otherwise, MySQL must query the The result set generates a temporary table, and the filesort operation is performed after the connection is completed. At this time, EXPLAIN outputs "Using temporary; Using filesort".
Improve query efficiency and
use indexes correctly
For the convenience of explanation, here is a demo:
DROP TABLE IF EXISTS user;
CREATE TABLE user(
id int AUTO_INCREMENT PRIMARY KEY,
user_name varchar(30) NOT NULL,
gender bit(1) NOT NULL DEFAULT b’1’,
city varchar(50) NOT NULL,
age int NOT NULL
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE user ADD INDEX idx_user(user_name , city , age);
复制代码
What kind of index can be used?
**Full match: **SELECT * FROM user WHERE user_name='JueJin' AND age='5' AND city='Shanghai'; (it has nothing to do with the order of query conditions after where)
Matching the leftmost prefix: (user_name ), ( user_name, city), (user_name, city, age) (the order of satisfying the leftmost prefix query condition has nothing to do with the order of index columns, such as: (city, user_name), (age, city, user_name))
**Matching column prefix: **SELECT * FROM user WHERE user_name LIKE'W%'
**Matching range value: **SELECT * FROM user WHERE user_name BETWEEN'W%' AND'Z%'
What kind of index cannot be used?
** Where query conditions do not include the leftmost index column in the index column, the index cannot be used: **
SELECT * FROM user WHERE city='Shanghai';
SELECT * FROM user WHERE age=‘26’;
SELECT * FROM user WHERE age=‘26’ AND city=‘上海’;
**Even if the query condition of where is the leftmost index column, the index cannot be used to query users whose username ends with N: **
SELECT * FROM user WHERE user_name LIKE'%N';
**If there is a range query of a column in the where query condition, all the columns on the right cannot use index optimization query: **
SELECT * FROM user WHERE user_name='JueJin' AND city LIKE'上%' AND age=31 ;
**The index column cannot be part of the expression, nor can it be used as a function parameter, otherwise the index query cannot be used: **
SELECT * FROM user WHERE user_name=concat(user_name,'PLUS');
Choosing the appropriate index column order The order
of the index columns is very important in the creation of the composite index. The correct index order depends on the query method of the query using the index.
For the index order of the composite index, the column with the highest selectivity can be placed in the index. In the first column, this rule is consistent with the selective method of prefix index. It
does not mean that the order of all composite indexes can be determined by using this rule. It is also necessary to determine the specific index order according to specific query scenarios.
Covering index conditions
if an index contains The value of all the fields to be queried is called a covering index
SELECT user_name, city, age FROM user WHERE user_name='Tony' AND age='28' AND city='Shanghai';
Because the fields to be queried (user_name, city, age) are included in the index column of the composite index, the covering index query is used to check whether the covering index is used. The value in the Extra in the execution plan is the Using index It is proved that the covering index is used, which can greatly improve the access performance.
Use index for sorting
If the index can be used for sorting in the sorting operation, the speed of sorting can be greatly improved. The following two points need to be met to use the index for sorting:
The column order after the ORDER BY clause must be consistent with the column order of the composite index, and the sorting direction (forward/reverse) of all sorting columns must be consistent
. The query field value must be included in the index column, and the covering index
sorting is available demo:
SELECT user_name, city, age FROM user_test ORDER BY user_name;
SELECT user_name, city, age FROM user_test ORDER BY user_name,city;
SELECT user_name, city, age FROM user_test ORDER BY user_name DESC,city DESC;
SELECT user_name, city, age FROM user_test WHERE user_name=‘Tony’ ORDER BY city;
排序不可用demo：
SELECT user_name, city, age FROM user_test ORDER BY user_name gender;
SELECT user_name, city, age, gender FROM user_test ORDER BY user_name;
SELECT user_name, city, age FROM user_test ORDER BY user_name ASC,city DESC;
SELECT user_name, city, age FROM user_test WHERE user_name LIKE'W%' ORDER BY city;
Suggestions for data acquisition
Do not return data that is not required by the user program to limit the number of returns
LIMIT: MySQL cannot return the amount of data as required, that is, MySQL will always query all the data. The use of the LIMIT clause is actually to reduce the pressure of network data transmission, and does not reduce the number of rows read.
Remove unnecessary columns
The SELECT * statement takes out all the fields in the table, regardless of whether the data in the field is useful to the calling application, this will waste server resources, and even have a certain impact on the performance of the server.
If the structure of the table changes in the future , Then the SELECT * statement may fetch incorrect data. When
executing the SELECT * statement, you must first find out which columns are in the table before you can start executing the SELECT * statement, which may cause performance problems in some cases.
Use the SELECT * statement Will not use the covering index, which is not conducive to query performance optimization
. Advantages of using the index correctly
Avoid full table scans For
single table queries, full table scans need to query every row. For
multiple table queries, full table scans need to retrieve at least every row in all tables.
Increase speed.
Quickly locate the first row of the result set.
Exclude irrelevant results
for MIN () or MAX() value does not have to check every row.
Improve the efficiency of sorting and grouping.
Avoid
the cost of row loop-up index
if covering index can be used . If there are too many indexes, data modification will become slow
. Need to be updated.
High pressure for write-intensive environments.
Indexes consume too much disk space.
InnoDB storage engine stores indexes and data together.
Disk space needs to be monitored.
Indexing best practices.
Consider using indexes as follows
Columns in the WHERE clause
ORDER BY or GROUP BY clauses in the
table join condition column
Consider using prefix indexes for string columns
More quickly compared to loop up
to reduce disk I / O
considered low SELECT statement efficiency
avoid full table scan
attempt to increase the index
WHERE clause
table join conditions
using ANALYZE TABLE gather statistics
consider optimizing the storage engine layer
tuning table connection method
in Add an index on the column of the ON or USING clause
Use SELECT STRAIGHT_JOIN to force the table join order
Adding an index
join on the ORDER BY and GROUP BY columns is not necessarily more efficient than the subquery
This article comes from the php Chinese network mysql video tutorial column: https: //www.php.cn/course/list/51.html