MySQL：关于INDEX使用情况，LIKE 123和= 123之间的差异

Question

I am experiencing a very strange behaviour which just turned out to be a matter of using the correct operator in my where condition.

Assume the following table structure with some million entries:

CREATE TABLE `obj` (
  `obj__id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `obj__obj_type__id` int(10) unsigned DEFAULT NULL,
  `obj__title` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__const` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__description` text COLLATE utf8_unicode_ci,
  `obj__created` datetime DEFAULT NULL,
  `obj__created_by` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__updated` datetime DEFAULT NULL,
  `obj__updated_by` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__property` int(10) unsigned DEFAULT '0',
  `obj__status` int(10) unsigned DEFAULT '1',
  `obj__sysid` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__scantime` datetime DEFAULT NULL,
  `obj__imported` datetime DEFAULT NULL,
  `obj__hostname` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `obj__undeletable` int(1) unsigned NOT NULL DEFAULT '0',
  `obj__rt_cf__id` int(11) unsigned DEFAULT NULL,
  `obj__cmdb_status__id` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`obj__id`),
  KEY `obj_FKIndex1` (`obj__obj_type__id`),
  KEY `obj_ibfk_2` (`obj__cmdb_status__id`),
  KEY `obj__sysid` (`obj__sysid`),
  KEY `obj__title` (`obj__title`),
  KEY `obj__const` (`obj__const`),
  KEY `obj__hostname` (`obj__hostname`),
  KEY `obj__status` (`obj__status`),
  KEY `obj__updated_by` (`obj__updated_by`)
) ENGINE=InnoDB AUTO_INCREMENT=7640131 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

A very simple select with two conditions ordering by obj__title with a limit of 500 performs quiet slow (500ms):

SELECT SQL_NO_CACHE * FROM obj WHERE (obj__status = 2) AND (obj__obj_type__id = 59) ORDER BY obj__title ASC LIMIT 0, 500;

Without the "ORDER BY obj__title" it runs like a charm (<1ms).

EXPLAIN SELECT is telling me that MySQL is performing a filesort and not using the obj__title index. So, ok, it is quiet obvious that this query is slow:

id  select_type table   type    possible_keys   key key_len ref rows    Extra
1   SIMPLE  obj index_merge obj_FKIndex1,obj__status    obj_FKIndex1,obj__status    5,5 NULL    1336    Using intersect(obj_FKIndex1,obj__status); Using where; Using filesort

When i am forcing the index obj__title to use with FORCE or USE INDEX, mysql is not using the other indexes resulting in a very poor performance again. But nevermind, it is quiet obvious that the poor performance has something to do with the combination of the two conditions and the order by.

Now that i spend hours on investigating on optimizing this query i came up with a very simple exchange: I exchanged the operator of my conditions from = to LIKE. So my query is like:

EXPLAIN SELECT SQL_NO_CACHE * FROM obj WHERE (obj__status LIKE 2) AND (obj__obj_type__id LIKE 59) ORDER BY obj__title ASC LIMIT 0, 500;

This is what happened..

id  select_type table   type    possible_keys   key key_len ref rows    Extra
1   SIMPLE  obj index   obj_FKIndex1,obj__status    obj__title  768 NULL    500 Using where

Query performance is 150ms. I was shocked actually.

I am not really happy with the speed but at least it is performing ok.

But what I would really like to know is why LIKE is using the index, and = does not? I did not found any hints on that on the MySQL documentation. Only a few notes about LIKE being case insensitive and LIKE acting a bit different for VARCHARS > 255, or any other CHAR or TEXT fields.. No single word about it's integer behaviour.

Can someone shed light on this situation? Any Database design or query tips to speed up the query more are very welcome as well!

Answer 1

For this query:

SELECT SQL_NO_CACHE *
FROM obj
WHERE (obj__status = 2) AND (obj__obj_type__id = 59)
ORDER BY obj__title ASC
LIMIT 0, 500;

The best index is obj(obj__status, obj__obj_type__id, obj__title) .

Otherwise, I would expect an index on one of the two where fields.

However, when you use like , you are comparing numbers to strings. This generally prevents an index from being used. The only possible index is for the order by , which happens to work in your case.

But, the proper index should have better performance.

Answer 2

The ORDER BY has to satisfied before the LIMIT . If there are a bloatload of rows, and MySQL performs a sort operation ("Using filesort") shown in the Extra column, that can be expensive.

MySQL can also satisfy an ORDER BY obj__title without performing a sort operation, by making use of an index with a leading column of obj__title . And that's what you see happening when you change the predicates. EXPLAIN shows that the index on obj__title is being used, there's no sort operation. But MySQL has to inspect each row, to see if it satisfies the predicates or not.

The LIKE predicate is causing the column to be evaluated in a string context, rather than numeric. That is, MySQL has to perform an implicit conversion from integer to varchar. And that prevents MySQL from using the index to satisfy the predicates. MySQL is basically being forced to do the conversion for every row in the table, in order to evaluate the predicate.

---

For best performance of that first query:

  SELECT SQL_NO_CACHE * 
    FROM obj 
   WHERE obj__status = 2
     AND obj__obj_type__id = 59
   ORDER BY obj__title ASC
   LIMIT 0, 500

You'd want an index with leading columns:

 .... ON obj (obj__status, obj__obj_type__id, obj__title)

Then, MySQL could satisfy both of the equality predicates and the order by making use of the single index.

Note that this makes the index on just the single column obj__status redundant. Any query making use of the index on obj__status could make use of the new index.

Answer 3

Your first select needs this composite index. (I take the liberty of removing the "obj_" which just clutters the SQL.)

INDEX(type_id, status, title)

MySQL rarely uses more than one index in a query; this 3-column index is suited for WHERE status=(const) AND type_id=(const) ORDER BY title . I see that it used "index intersect" to try to compensate for the lack of a suitable composite index, but only partially.

Perhaps the optimizer looked at LIKE and said "Punt! I give up on using numeric comparisons, so let's not use either index on type_id or status. Instead, let's see if we can avoid the filesort by using INDEX(title) ". And it happened to be better.

There is another thing that makes that filesort especially costly. "Using temporary" and "Filesort" prefer to do everything in RAM via a MEMORY table. But several things can prevent that. One is fetching of a TEXT field, which you do ( SELECT * which includes description TEXT ). I doubt if the optimizer noticed that. But the timings seem to have.

For more tips on indexing, see my index cookbook . Meanwhile, use LIKE only on strings, not numeric values.