Detailed explanation of index and FROM_UNIXTIME problems in mysql

This article mainly introduces the relevant information about index and FROM_UNIXTIME in mysql. Friends who need it can refer to

Zero, background

I received a lot of alarms this Thursday. I checked with the DBA and found a slow query.

After simply collecting some information, I found that this slow query problem is deeply hidden. Many people including the DBA did not know the reason after asking.

1. Problem

There is a DB with a field defined as follows.

The index is as follows:

Then I wrote a SQL as follows:

Finally one day the DBA came over and gave me a running message, saying that this SQL was slow SQL.

I was speechless. My DB is indexed and SQL is carefully optimized. Why is SQL slow?

When asked why it is slow SQL, the DBA couldn’t answer it. Even the colleagues around me couldn’t answer it.

I secretly thought that I had encountered a deeply hidden knowledge point.

There are two suspicious places: 1. There are 6 indexes. 2. The rvalue is FROM_UNIXTIME function.

So I checked the official MYSQL documentation and found that 6 were not problems.

All storage engines support at least 16 indexes per table and a total index length of at least 256 bytes.
Most storage engines have higher limits.

So I suspect that the problem is the FROM_UNIXTIME function.

Then look at the INDEX section of MYSQL and find some clues.

1.To find the rows matching a WHERE clause quickly.
2. To eliminate rows from consideration.
If there is a choice between multiple indexes, MySQL normally uses the index that finds the smallest number of rows.
3.If the table has a multiple-column index, any leftmost prefix of the index can be used by the optimizer to look up rows.
4. MySQL can use indexes on columns more efficiently if they are declared as the same type and size.
Comparison of dissimilar columns (comparing a string column to a temporal or numeric column, for example) may prevent use of indexes if values ​​cannot be compared directly without conversion.

When I saw Article 4, it was mentioned that different types may lead to no indexing. Could it be that the return value of FROM_UNIXTIME cannot be converted into the string type?

So query the return value of FROM_UNIXTIME function.

MySQL FROM_UNIXTIME() <a href="http://www.php.cn/wiki/135.html" target="_blank">return</a>s a <a href="http://www.php.cn/wiki/1255.html" target="_blank">date</a> /datetime from a version of unix_timestamp.

returned It is a time type, what about forcing it to be converted to a string type?

This time you can see that the index is used and only one piece of data is scanned.

2. Conclusion

This time, you can use the index by forcing the return value of FROM_UNIXTIME to be converted.

So this SQL cannot use the upper index because the types of rvalues ​​and lvalues ​​are inconsistent. .

Okay, let’s not say more. This article is just an interlude. Let’s continue to introduce the algorithm later.

The above is the detailed content of Detailed explanation of index and FROM_UNIXTIME problems in mysql. For more information, please follow other related articles on the PHP Chinese website!