This article is a certain degree of sql base, but if there are issues such as the use of the index tuning mode not quite clear on who sql, he pointed out a way to use.
This article is not a pure original, is a combination of previous blog, write a summary of their own blog.
mysql join a collection of usage: https://blog.csdn.net/lukabruce/article/details/80568796
Index, sub-library sub-table, sql wording, etc., will affect the sql performance.
concept:
1. Database transaction ACID properties
4 feature of the database transaction:
atomicity (Atomic): a plurality of operations in the transaction, integral, or are successful or failed; All or Nothing.
Consistency (Consistency): After the transaction operations, in which the state of the database and business rules are the same; for example, a, b account after each transfer, the total amount unchanged;
isolation (isolation): between serial execution of multiple transactions like the same, do not affect each other;
persistent (Durability): after the transaction is committed persisted to permanent storage.
3. MySQL difference between the RC and RR isolation levels
MySQL database default isolation level RR, but the reality is that the use of RC and RR isolation levels are many. Like Taobao, RC Netease are using isolation level. So what difference does it in MySQL RC and RR? How do we choose? Why MySQL as the default RR isolation level it?
4. RC and RR difference in terms of the lock
1> Obviously RR support gap lock (next-key lock), while RC is no gap lock. Because MySQL needs of RR gap lock to solve the problem of phantom read. RC isolation level and is allowed to read and unrepeatable phantom read. Therefore, RC concurrency is generally better than the RR;
2> RC isolation levels, after passing through the filter where conditions do not meet the line lock on the recording conditions, will be freed (although this would undermine the "two-stage lock principle"); however RR isolation level, even if does not meet the conditions where record, will not release row locks and gap lock; lock it from the point of view, RC concurrency should be better than RR; additional insert into t select ... from s where s statement lock on the table is not the same.
5. Review the database has been locked and the transaction which lines
Two, mysql row locks, table locks
For myisam table select a locked table, it will lead to other operating hangs in a wait state.
For innodb tables select will not lock table. In fact, here to use snapshots. Snapshot not discussed here.
Common innodb, select ... for update, be sure to pay attention to where + id or unique index field filter, otherwise it will lead to the table lock.
Optimization tips:
1. Server optimization, e.g. max_connection big change, connection_timeout modified
2. optimize client connections, multiplexed connection pool
3. architecture level.
1) using the cache (e.g. redis).
2) If there is not open clusters, separate read and write.
3) Even if a cluster read and write separation, assuming the amount of data of millions how is also slow, then sub-library sub-table
4. Configure slow_query_log, for a long time analyzing the execution time exceeds the set sql, but also the consumption of certain properties; statistical analysis tools can be used with mysqldumpslow slow query bin directory.
sql optimization:
1. If the paging query is too complicated, you can find out paged data, then directly check the details specified burst data column.
2.case when statement, written before where performance impact is not too large, but can be time consuming to write in the back where
3.mysql large amounts of data using the limit tab, as the page number increases, the search efficiency is low.
select * from product limit 10, 20 0.016秒
select * from product limit 100, 20 0.016秒
select * from product limit 10000, 20 0.094秒
select * from product limit 400000, 20 3.229秒
Covering the use of the index table to speed up query paging
we all know, the use of the index query if the statement contains only the index column (covering indexes), then this situation will soon queries.
SELECT * FROM product WHERE ID > =(select id from product order by id limit 866613, 1) limit 20 或者
SELECT * FROM product a JOIN (select id from product order by id limit 866613, 20) b ON a.ID = b.id
Query time of 0.2 seconds!
select id from collect where vtype = 1 limit 90000,10; // add the search (vtype, id) such a composite index, will quickly
2. indexing works
mysql innodb is now mainly used index Tree structure B +, B + Tree is absolutely balanced tree, it needs to know certain pieces of data that go right or left, can be a good reduction io operation between main memory and hard drives, to speed up query speed. (Case: B is not equivalent to balanced binary tree, which is a multiple search trees, B-trees, and various data are stored it in the leaf node, and between the leaf nodes are connected by pointers, but balance has tree.)
Storage structure mysql index of general use B + tree, in fact it has hash structure storage, hash structure to find low complexity o data (1), while the B + tree generally only o (log n), so why choose b + tree?
analysis:
1. Why is it not a binary tree?
Because we have to consider the impact of disk IO, it is relative to memory is very slow. Database index is stored on disk, and when the amount of data, the overall index can not be loaded into all of the memory, it can be loaded one by one (corresponding to the node of the index tree) each disk page. So we want to reduce the number of IO
2. Why not use hash?
And indexes in the database is generally on the disk, large volumes of data may not be the case once loaded into memory B + tree design can allow data to load batches, while the lower height of the tree, to improve search efficiency.
This and related business scenarios. If you choose a data only, it is indeed Hash faster. But the database will often select multiple, this time due to the B + tree index orderly, and have linked list, its query efficiency ratio Hash on a lot faster.
Generally know, not in <> is null those not taking the index, not rote is very simple, because it is using b + tree indexes do not know under which look from the left or the path to the right of the tree, which can only full table search, inefficiency, here is more validation, which joint index of the underlying I do not understand.
For chestnuts on, we all know that the data length of the index column is too long will affect the efficiency of the index, but the actual is why?
In fact, because b + tree index mysql used, all data is placed on a leaf node, so when the share index of the column size is too large, it will lead to a leaf node for each data storage can not be too much, resulting in appear more leaves, more leaves will lead to an increase in the number of layers of the tree, the number of layers deep, and when the number of times gone io Find also increased, so low on efficiency.
2. Run Tuning
IDEA tool recommended XRebel, which may quickly locate the sql efficiency is too low
test
instruction:
explain extended select * from tablename;
show warnings;
Use instructions explain explain extended analysis can help us select statement, which can be targeted to do optimization.
show warnings you can see we write sql to how it is optimized, it can be found whether visually excellent own sql.
Here is a test table:
CREATE TABLE `t_stu` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
Command is input explain extended xxx Results a :
show warnings; instruction as a result two :
The results can be seen two very clear we write sql automatically fill the whole column names
Resolve
So how to analyze the results of it?
A summary of the results :( this is a quote from Bowen mentioned above)
They came up with a few tips could easily misunderstood:
-
In general, the column can be NULL NOT NULL will not change how much help performance, but if you plan to create an index on the column, the column should be set to NOT NULL.
-
Specifies the width integer types, such as INT (11), with no eggs. INT 32-bit (4 bytes) of storage space, it has been determined that indicates a range, the INT (. 1), and INT (20 is) are calculated and stored for the same.
-
UNSIGNED allowed to express negative, roughly the upper limit of positive number doubled. TINYINT such storage is -128 to 127 range, and the range is stored UNSIGNED TINYINT 0 - 255.
-
Generally speaking, there is not much need to use DECIMAL data type. Even when you need to store financial data, you can still use BIGINT. Such as the need to precise parts per million, then the data may be multiplied by one million and then use BIGINT storage. This avoids floating point calculations are not precise and accurate calculation of DECIMAL costly problem.
-
TIMESTAMP uses 4 bytes of storage space, DATETIME 8 bytes of storage space. Thus, TIMESTAMP can only express 1970--2038 years, the range is much smaller than indicated DATETIME, and TIMESTAMP values due to the different time zones and different.
-
Not used in most cases enumerated type is necessary, which is a drawback enumerated list of strings is fixed, add and remove strings (enum option) must use the ALTER TABLE (if only just at the end of the list of additional elements, do not need to rebuild the table).
-
schema column not too much. The reason is needed between the server layer and the memory layer by the line buffer engine copy format data storage engine API works, then the server layer decoding buffer content into the columns, the cost of this conversion process is very high. If the column too many columns and few actually used, it may cause high CPU.
-
Large table ALTER TABLE is very time-consuming, MySQL performs most of the results table modification operation is to create a new structure with sheets of empty tables, find out from the old table all the data into a new table, and then delete the old table. Especially in the case when memory and the table is so big, but there is still much of the index, it takes longer. Of course, there are some clever but useless can solve this problem, are interested can look yourself.
Indexing basis
Back to the table: innodb query is the second index, the leaf nodes of the B + tree found not the whole data (index InnoDB two leaves only the index key stored key and a primary key), the primary key index to obtain further B + Find a tree to go again, this is back to the table.
Covering indexes: Same as above, but the exception is select the secondary index field from XX, because the query column is only secondary index fields, indices in the secondary index B + tree to find the time, the leaf nodes have the desired data, and not back to the table .
mysql whether to use the index, cost-based optimizer determines the main basis. Compare intelligent, so some die sets of rules are not in line.
For example query band is not equal, not in. A lot of people say the index will lead to failure, but not necessarily.
For Example, assuming increment primary key table, select * from table where id = 1;! Index will go, because the optimizer find this case, find the leaf node id = 1, because the leaf nodes are ordered, so find direct leaf node to the data after 1, which is the index to go up, so it is best to be flexible judge.
