使用多个索引优化MySQL查询

Question

I have a query:

SELECT items.*
FROM items
INNER JOIN other on other.some_key = items.some_key
WHERE
  items.partition_id = 7 AND
  items.created_date > '2016-01-01 00:00:00' AND
  (
    other.name like '%user query%' OR
    match (fulltext_candidate) against ('+user* +query*' IN BOOLEAN MODE) OR
    items.some_varchar like '%user query%'
  )
ORDER BY items.created_date
LIMIT 20 OFFSET 0;

I added multiple indexes

ALTER TABLE `items` ADD INDEX `partition_id` (`partition_id`)
ALTER TABLE `items` ADD FULLTEXT `fti` (`fulltext_candidate`)
ALTER TABLE `items` ADD INDEX `created_date` (`created_date`)
ALTER TABLE `items` ADD INDEX `some_varchar` (`some_varchar`)
ALTER TABLE `other` ADD INDEX `name` (`name`)

The query is slow. The slow query log shows the query scanning all rows of the items table. I believe MySQL is only using one index on the query. If I do a reduced query, where I only include one column in the WHERE clause, the query is very fast.

How can I build a single index that will optimize this query, using both fulltext and normal indexes?

Answer 1

This is too big for a comment.

This looks odd.

inner join other on other.some_key = items.some_key

I'm assuming some_key is indexed but has a very weird name? If it is and it's not hitting an index on the query as specified then I reckon it might be doing a full table scan because that's the fastest way to get the data. I'd need to know more about your data etc to help. As an example. In small tables the DB might full table scan them in because it's a few kilobytes of data and you may access it in your query in multiple ways. The optimizer looks at an index and makes a call on how much it can filter the result set by, if this number is low it won't use it.

Answer 2

I'm assuming you've removed some detail from the query - "other.some_key" and "items.somekey" (your join columns) should definitely be indexed.

Versions of MySQL before 5.0 can only use a single index per query. An explain will tell you what's going on in this case.

There are a couple of criteria in your query that will not use an index, no matter what you do:

other.name like '%user query%' 
items.some_varchar like '%user query%'

have a leading wildcard, and the index will do you no good (can you convert to free text search instead?). It's not clear how much of a performance hit this is causing - if the rest of your query filters down the number of matching records to hundreds or thousands, it's probably not making a difference. Again, EXPLAIN will help out.

If you can remove the leading wild card, and can add "some_varchar" to the compound index, it should help.

For your query, I'd create a single, compound index; that way, the optimizer doesn't second guess you.

ALTER TABLE `items` ADD INDEX `compound` (some_key, partition_id, created_date)

Answer 3

Answer

Have these; no others will be useful for your query (or any discussed variant):

items: INDEX(partition_id, created_date)
other: INDEX(some_key)

Comments on all the other chatter:

The ORs prevent any use of indexes (such as your FULLTEXT ) of columns mentioned in them. That is, removing the leading % still won't do any good - because of the OR .

(some_key, partition_id, created_date) makes it unusable for the WHERE and ORDER BY .

Even if you could use the "index merge", it is sooooo rarely invoked that it is not worth considering. (And it is only a crude bandaid.)

When you have a MATCH ... that could use a FULLTEXT index, only the FULLTEXT index will be used. That is, if it can be used. Again, the OR prevents it for your case. Sure, "compound" indexes are very useful; but the optimizer always assumes that FULLTEXT is more useful.

Since FULLTEXT cannot be used, the optimizer should move on to INDEX(partition_id, created_date) and find it useful.