在mySQL中为特定查询优化索引

Question

I have a fairly simple query that is taking about 14 seconds to complete and I would like to speed it up. I think I have the correct indexes in place, but I'm not sure...

Here is the query

SELECT *
FROM opportunities
WHERE cid = 7785
  AND STATUS != 4
  AND otype != 200
  AND links > 0
  AND ontopic != 'F'
ORDER BY links DESC
LIMIT 0, 100;

Here is the table schema

CREATE TABLE `opportunities` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `cid` int(11) NOT NULL,
  `url` varchar(900) CHARACTER SET utf8 NOT NULL,
  `status` tinyint(4) NOT NULL,
  `links` int(11) NOT NULL,
  `otype` int(11) NOT NULL,
  `reserved` tinyint(4) NOT NULL,
  `ontopic` varchar(3) CHARACTER SET utf8 NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `cid` (`cid`,`url`),
  KEY `cid1` (`cid`),
  KEY `url` (`url`),
  KEY `otype` (`otype`),
  KEY `reserved` (`reserved`),
  KEY `ontopic` (`ontopic`),
  KEY `status` (`status`),
  KEY `links` (`links`),
  KEY `ontopic_links` (`ontopic`,`links`),
  KEY `cid_status_otype_links_ontopic` (`cid`,`status`,`otype`,`links`,`ontopic`)
) ENGINE=InnoDB AUTO_INCREMENT=13022832 DEFAULT CHARSET=latin1

Here is the result of the EXPLAIN command

id: 1
select_type: Simple
table: opportunities
partitions: null
type: range
possible_keys: cid,cid1,otype,ontopic,status,links,ontopic_links,cid_status_otype_links_ontopic
key: links
keylen: 4
ref: null
rows: 1531552
filtered: 0.33
Extra: Using index condition; Using where

Thoughts / Questions

Am I reading it correctly that it is using the "links" key to do the query? Why wouldn't it use a more complete index, like the cid_status_otype_links_ontopic which covers all the conditions of my query?

Thanks in advance!

As requested

There are 30,961 results that match the query when you remove the LIMIT 0,100. Interestingly, the "count()" command returns almost instantaneously.

Answer 1

• What you have must plow through all of the rows, using your 5-column index, then sort the results and deliver 100 rows.

• The only index likely to be useful is INDEX(cid, links) . This is because cid is the only column being tested with = , then having links might be useful for the ORDER BY and LIMIT . There is still the risk that the != tests will require filtering a lot of rows.

• Are status and otype multi-valued? If either has only 2 values, then turning the != into = and adding it to the index would be beneficial.

• Do you really need all the columns ( SELECT * )? If not, and if you don't need any big columns ( url ), then you could go with a 'covering' index.

More on writing indexes .

Answer 2

It's a funny thing about using inequality comparisons, that they count as range conditions.

That is, equality matches one value, but anything other than equality ( != , > , < , IN , BETWEEN ).

By matching multiple values, it means that only the first column in an index used in a range condition is going to be optimized. You'd think that your index cid_status_otype_links_ontopic has all the columns mentioned in conditions of your query, but only the first two will be used. The first because you have an equality comparison for cid . The second because the next column is used in an inequality comparison, and then that's where it stops using columns from the index.*

Evidence: if you can force that index to be used, you should see the keylen field of the EXPLAIN result show only 5, which is the size of cid (4 bytes) + status (1 byte).

The MySQL optimizer apparently has predicted that it would be more beneficial to use your links index, because that allows it to access the rows in index order, which is the same as the sort order you requested with your ORDER BY .

Evidence: you don't see "Using filesort" in your EXPLAIN notes.

Is that really better than using one of the other indexes? Maybe, maybe not. The optimizer's predictions aren't always perfect.

You can use an index hint to override the optimizer's choice:

SELECT * FROM opportunities USE INDEX (cid_status_otype_links_ontopic) WHERE ...

Try that out, do the EXPLAIN of that query and compare it to your other EXPLAIN. Then execute both queries and see which is reliably faster.

(* Actually, I have to add a footnote about the index column usage. MySQL 5.6 and later can do a little bit better than just the two columns, when you see the note "Using Index Condition" in the EXPLAIN. But it's not quite the same. You can read more about that here: https://dev.mysql.com/doc/refman/5.6/en/index-condition-pushdown-optimization.html )