To be honest, this problem can involve a lot of core knowledge of MySQL, a lot can be pulled, just like when you want to test your knowledge of computer network, ask you "Enter after entering a URL, exactly what happened," just like to see you can tell how much.
Tencent truth before the interview, also asked this question, but the answer is very bad, not thought about before-related causes, resulting in a sudden pull it out. So today, I take you to pull in detail about what the reasons, I believe you will be harvested after watching, or you hit me.
Start loading force: Category talk
A SQL statement is executed very slowly, and that each execution is very slow? Or in most cases it is normal, occasionally very slow? So I think we scored two situations to discuss.
1, in most cases it is normal, but occasionally there will be very slow conditions.
2, in the case of the same amount of data, this SQL statement has been executed very slowly.
For both cases, we have to analyze what may be the causes.
For occasional slow case
In most cases a normal SQL occasionally to appear very slow, for this situation, I feel that writing this SQL statement in itself is no problem, but other causes, that would be what causes it?
Database refresh dirty pages I had no choice ah
When we want to insert data into a database, or to update a data, we know that the database will be in memory in the data corresponding to update the field, but after the updates that field will not immediately synchronized persisted to disk in go, but to write these updated records to the redo log diary to wait until free time, by redo log in the diary to the latest data is synchronized to disk to go.
However, redo log where the capacity is limited, if the database has been very busy, and very frequently updated, this time to redo log will soon be filled, and this time there is no way to wait until idle time and then synchronize the data to disk the only other operational pause, threw himself to synchronize the data to disk to go, but this time, it will lead us to your normal SQL statement executed suddenly very slow , so that the database is in sync data to disk time, it may lead to our SQL statements executed very slow.
How do I can not get a lock
This is easier to think of it, this statement we want to execute, just this statement related to the table , with others, and locked, and we can not get a lock, only slowly waiting for someone to release the lock. Alternatively, the table is not locked, but you want to use a line to be locked, and this time, I have no way ah.
To determine whether it is waiting for a lock, we can show processlist this command to view the current status Oh, I have to remind you, the best record some commands about, anyway, I was asked several commands, do not know how to write, huh, huh.
We analyze visitors down the second case, I think the analysis of the second condition is the most important
For the case has been so slow
If a large amount of data in the same situation, this SQL statement is executed every time so slow, it is necessary to take under consideration your SQL writing, we come under the following analysis What can cause our SQL statements executed far from ideal.
Let us assume there is a table, the following table has two fields, namely primary key id, and two general fields c and d.
mysql> CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
Cut to the heart, and useless to index
No access to the index, I think the reason is that many people can think of, for example, you want to query this statement
select * from t where 100 <c and c < 100000;Fields not indexed
Not just your c fields on the index, so sorry, can only take full table scan, you will experience the fun does not bring the index, so, this time led to this query is very slow.
Field has an index, but the index is not used
Well, this time you add a field to c the index, and then query a statement
select * from t where c - 1 = 1000;I want to ask you a question, like this when the query will use the index query anyway?
Answer is no, if we do the operation on the left side of the field, then I'm sorry, at the time of the query, the index will not spend, so, we should note that there is an index on the field, but because of their own negligence , resulting in indexing system does not use the case of a.
Correct query should be as follows
select * from t where c = 1000 + 1;Some might say, have the right operation can spend an index? Is the database will not automatically help us optimize it, automatically c - 1 = 1000 are automatically converted to c = 1000 + 1.
Sorry, it does not help you, so you have to pay attention.
Functions operating result in no access to index
If we in the query, the fields using the function to operate, but also will lead to no access to the index, for example,
select * from t where pow(c,2) = 1000;I'm just here to do an example, assume the function pow is seeking c n-th power, in fact, may not pow (c, 2) the function. In fact, this and do the above operation on the left is also very similar.
So, the statement executed very slow, it may be that the statement did not use the index, but the specific cause is valid and no access to index it, you have to analyze the three reasons I listed above, it should be more of it appeared.
Oh, wrong indexed database itself
When we conduct a query operation, for example,
select * from t where 100 < c and c < 100000;We know that the primary key index and non-primary key index is different, the value of the primary key index is stored in the data entire row of the field , rather than the primary key value is not the entire row of fields stored on the index, and store the value of the primary key field . I can not understand look at this article: Interview Tips: MySQL index-related There are differences when it comes to primary key index and non-primary key index
In other words, if we take the index c of this field, then eventually to query the value of the corresponding primary key, then, then move the primary key index based on the value of the primary key, query the entire row of data returned.
Well pull so much, in fact, I just want to tell you, even if you have an index on c field, the system does not necessarily take the index c on this field, but there may be a full table scan to scan directly to find out All compliant data 100 <c and c <100000 of.
Why is this so?
What is to take fewer rows c index scan of a small number of rows, or scan directly to a full table scan of it: in fact, this is the system in the implementation of this statement would be predicted? Obviously, the fewer the number of scanning lines, of course, the better, because the fewer the number of scan lines, means that I / O operations, the less often.
If you are scanning the entire table, then the number of sweeps is the number of the table of the head office is assumed to be n; then if taking the index c, we find the master key by the index c, have through the primary key index came to our entire line data, that is to say, you need to take two indexes. Moreover, we do not know conform 100 c <and c <data 10000 of how many lines this condition, if the table is all the data are in line with it? This time means that not only take c index number of scanning lines is n, each row of data at the same time had to go twice index.
So, the system is likely to take the full table scan instead of following the index. That system is how to judge it?
Judgment comes from forecasting system, that is, if the index go c field, the system will go c field prediction about how much the need to scan the index. If the predicted number of rows to scan a lot, it may not go directly to the index table scan the whole.
So the question is, how the system is forecast to judge it? Here, I tell you the system is how to judge it, although this time I have written a neck blinded.
System through discrimination index to judge, on an index more different values, the same index value means the less occurs, means higher discrimination index. We also call the discrimination of the base , i.e. the higher the degree of distinction, the greater base. So, the larger the base, it implies conformity 100 <c and c <10,000 fewer number of lines this condition.
So, the higher the index of a base, take the index means that the query has an advantage.
So the question is, how do you know this base index it?
Of course, the system is not going to get a traversal of all indexed base, price is too great, the indexing system is by traversing part of the data, that is, through sampling methods to predict the base of the index.
Pulled so much focus here , is actually sampled, then there may be mistakes circumstances, that is, c base this index is actually great, but when sampling is very unfortunate, this base prediction index to be small. For example, part of the data that you sampled just a very small base, and then mistaken for an index of a very small base. Oh then, the system will not go c indexed, go directly to all scanned .
So, I said so much, concludes: Due to statistical errors, resulting in the system not taking the index, but to go a full table scan , which also leads to very slow reason we executed SQL statement.
Here I declare what, the system determines whether to take the index to predict the number of scanning lines is only one of the reasons, whether this query requires the use of a temporary table, and so is the need for the sort will affect the choice of system.
But then, sometimes we can be queried by way of forcibly taking the index, for example,
select * from t force index(a) where c < 100 and c < 100000;We can also
show index from t;To query the index base and actual compliance, and if the actual very consistent with it, we can re-base statistics to the index, you can use this command
analyze table t;To statistical analysis again.
Since the index predicts the wrong base, it also means that when we have multiple index query, the system may also have chosen the wrong index Oh , this may also be a reason for slow SQL execution.
Well, on the first pull so much, and that time you pulled out so much that I think has been great, to make a summary below.
### to sum up
The above is my summary and understanding, the last part, I'm afraid a lot of people do not understand the database index turned out to be wrong , so I explained in detail what, here I make a summary of the above.
A SQL execution is slow, we have to discuss two cases:
1, in most cases normal, occasionally very slow, then the following reasons
(1), flushing dirty pages in the database, such as the need to synchronize filled redo log to disk.
(2), when executed, locks encountered, such as table locks, row locks.
2, this SQL statement has been executed very slowly, then the following reasons.
(1), no access to the index: For example, the field is not indexed; fields due to the calculation, the index can not function operation results.
(2), the wrong database index.
