Comments on: 3 ways MySQL uses indexes

By: Pavel Cibulka

Pavel Cibulka — Mon, 12 Sep 2011 09:26:07 +0000

Peter,

thanks for response. Percona blog is really great source of knowledge with many helpful people. I hope we will see 3rd edition of “High Performance MySQL” book soon.

By: Peter Zaitsev

Peter Zaitsev — Mon, 12 Sep 2011 02:31:39 +0000

Pavel,

It is not the same as sex in (‘M’,'F’) is enumerated range while A>=0 is not. MySQL would only use full index when leading parts are enumerated as soon as it is non enumerated range (as > < BETWEEN etc) this will be last key part to use.

By: Pavel Cibulka

Pavel Cibulka — Sat, 10 Sep 2011 16:02:28 +0000

Hi Peter,
I’ve been thinking about your example with index (A,B) and WHERE B BETWEEN 5 AND 10. What about rewrite it as WHERE A>=0 AND B BETWEEN 5 AND 10? It is similar to the example in your book (AND sex IN(‘m’, ‘f’)).

This will use index. It would be ok, if A have few different values. But could become slow, if A has many different values.

By: jay

jay — Wed, 21 Jul 2010 05:02:42 +0000

that you see more of it, I created 2 new indexes (on production data, not testing or random).
(sizes are different in production data. Type is int (4Bytes) not smallint and vector is varchar 255+2)

KEY `ty_fr` (`tree_type`,`date_from`),
KEY `ty_fr_to` (`tree_type`,`date_from`,`date_to`),
KEY `ty_fr_to_ve_de` (`tree_type`,`date_from`,`date_to`,`tree_vector`,`tree_depth`), – the real key used in app

FROM tree FORCE INDEX (ty_fr) :
key ty_fr
key_len 7
rows 11410

FROM tree FORCE INDEX (ty_fr_to) :
key ty_fr_to
key_len 10
rows 8492

FROM tree FORCE INDEX (ty_fr_to_ve_de) :
key ty_fr_to_ve_de
key_len 267
rows 7128

By: jay

jay — Wed, 21 Jul 2010 04:25:06 +0000

sizes of parts of the key in Bytes:
tree_type = 2B
tree_vector = 200B (ascii char)
date_from = 3B
date_to = 3B

From Explain in the article:
type : range
possible_keys : type_vector_to_from,type_vector_from_to,type_from_…
key : type_from_to_vector
key_len : 208

testing on different keys (also in the article) confirms the key lenght.

By: peter

peter — Wed, 21 Jul 2010 04:20:22 +0000

Jay,

So the question remains. How do you KNOW all key parts are actually used ?

By: jay

jay — Wed, 21 Jul 2010 04:05:59 +0000

Someone who aproved my comment changed the query. (propably symbols “more” and “less” made problems)
Look at the link, at the end of the article is the correct query.

date_from and date_to are true ranges.
And vector LIKE “0001%” is changed by optimizer to another range – vector >= “0001″ AND vector < "0002".

By: peter

peter — Wed, 21 Jul 2010 03:03:17 +0000

Jay,

In your case you have 4 clauses. 2 of them are EQ clauses and clauses on date_to and tree_vector are ranges. This query should use 3 key parts of this index hence only one range. If you think it is different can you explain why do you think so ?

By: jay

jay — Tue, 20 Jul 2010 12:51:16 +0000

Quote: “once MySQL runs into the interval range it will not use any further index parts.”
WRONG!

Triple range lookup:

EXPLAIN SELECT *
FROM tree
WHERE 1
AND tree_type = “2220″
AND date_from = “0000-00-00″
AND date_to > “2010-06-01″
AND date_to <= "9999-12-31"
AND tree_vector LIKE "0001%"

The WHOLE key is used.
KEY `type_from_to_vector` (`tree_type`,`date_to`,`date_from`,`tree_vector`)

more in Slovak language :
http://kyberia.sk/id/5396760

In app, I'm already using multiple range lookups with speeds in miliseconds.
It's maybe difficult to make it work the first time, to make the correct index, and the correct WHERE, but it's worth it.

By: Ted Naleid » Batch Import Performance with Grails and MySQL

Ted Naleid » Batch Import Performance with Grails and MySQL — Thu, 01 Oct 2009 05:54:01 +0000

[...] you haven’t created many indexes before, I highly suggest reading this post on indexes on the mysql high performance blog. The executive summary is that multi-key indexes tailored to your query have a performance edge [...]