Как MySQL траверс индекса составного B-дерева для IN() и() выполняет поиск

Question

Я изучаю индексы и не могу полностью понять, как MYSQL может использовать индексы на всех для утверждений типа

IN() AND IN() ... AND IN() 

книга, которую я читаю говорит, что, когда у нас есть индекс (a, b, ...), но пользователь хочет найти b и мы имеем низкую мощность в a, мы можем использовать трюк и просто добавить IN ()

WHERE a IN ('x1', 'x2', ... 'all possible values go here') AND `b`>123 

Let У нас есть следующие данные:

x1 1 
x1 4 
x1 456 
x2 5 
x3 1 
x3 2 
x3 3 
x4 1234 

Как он может пересечь это дерево, чтобы удовлетворить запрос выше? Будет ли он просто создавать все возможные комбинации для IN-s и будет в значительной степени пересекать дерево для каждого из этих запросов?

WHERE `a`='x1' AND `b`>123 
WHERE `a`='x2' AND `b`>123 
... 

поэтому делает этот трюк ограниченной полезности, поскольку, как число увеличивается в-S, число всех возможных комбинаций IN резко возрастает, и мы должны бежать через B-дерева для каждого из этих комбинаций? Если это верно, означает ли это, что существует теоретическая точка, в которой обход индекса с IN будет медленнее, чем вообще не использовать индекс?

Answer 1

Он объединяет результаты с нескольких проходов. Итак, ваше предположение верно. :)

См http://dev.mysql.com/doc/refman/5.0/en/index-merge-optimization.html

Перед индекс сливает, MySQL не может удовлетворить такие запросы из индекса.

Answer 2

Вы правы.

MySQL использует ту же технологию для этого типа оптимизации IN, которую он использует при выполнении JOINs, а MySQL способен на большое количество JOIN, не оказывая заметного влияния на производительность.

Хотя стоимость может в конечном итоге достичь точки, в которой она становится заметной, она по-прежнему является преимуществом по сравнению с отсутствием индекса.

Не использовать индекс вообще выгодно только в том месте, где вы возвращаете большой процент строк. MySQL может принять решение, когда отказаться от индекса.