Why I added the index, SQL execution is so slow (a)?

In MySQL, there are some statements even if the same logic, the performance difference execute really great.

First throw a conclusion: If you want to use the index tree search function, it can not be handled index field values ​​using database functions, but does not change the index field values ​​at the same time, to achieve their own logic in SQL statements

Function operating condition field

We now assume that the system maintains a transaction table:

mysql> CREATE TABLE `tradelog` (
  `id` int(11) NOT NULL,
  `tradeid` varchar(32) DEFAULT NULL,
  `operator` int(11) DEFAULT NULL,
  `t_modified` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `tradeid` (`tradeid`),
  KEY `t_modified` (`t_modified`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

We insertion of five test data in the table:

insert into tradelog (id,tradeid,t_modified) values(1,'a','2017-03-15');
insert into tradelog (id,tradeid,t_modified) values(2,'b','2017-06-11');
insert into tradelog (id,tradeid,t_modified) values(3,'c','2017-07-03');
insert into tradelog (id,tradeid,t_modified) values(4,'d','2018-08-11');
insert into tradelog (id,tradeid,t_modified) values(5,'e','2018-09-12');

 

 SQL execution results

Next we need to query data 2016 to 2018, all in July.

SQL can be written:

select count(*) from tradelog where month(t_modified)=7;

We can explain command-line statement of the results of this analysis.

SQL execution results

That is, the statement uses t_modified index, row = 5, a statement on behalf of the full index scan, Using index coverage indication index.

So why is this so?

First, the operation performed by which index is determined by the optimizer, where the index may be used are primary key index and the index t_modified. In contrast to the index after the discovery of the size of the tree, t_modified index tree is smaller, so the optimizer chose to use t_modified index, but why would use the full index scan instead of an index tree way to find it? The reason is that the index tree lookup innodb way, because the same level of sibling nodes having sequential (similar to a binary search, data required order), order value index lock is destroyed, the optimizer can only choose full index scan way to execute a statement, so

Function operations on index fields, will destroy the order of the index value, the optimizer to give up the lead to take the index tree search.

If we want to use the index tree search function, it can not be handled index field values ​​using database functions, but does not change the index field values ​​at the same time, to achieve their own logic in SQL statements, SQL statements above do rewritten as follows:

select count(*) from tradelog where
(t_modified >= '2016-7-1' and t_modified<'2016-8-1') or
(t_modified >= '2017-7-1' and t_modified<'2017-8-1') or 
(t_modified >= '2018-7-1' and t_modified<'2018-8-1');

Then we use explain its analysis:

 

 SQL execution results

At this point we can see, at this time the statement is a way tree search, scan only three lines of data.