производительность MySQL, внутреннее соединение, как избежать использования временных и FileSort

Question

У меня есть таблица 1 и таблица 2.

Таблица 1 PARTNUM - ID_BRAND partnum является первичным ключом id_brand является "индексированный"

Таблица 2 iD_BRAND - BRAND_NAME id_brand является первичным ключом BRAND_NAME является "индексируется"

в таблице 1 содержится 1 млн записей и таблица 2 содержит 1.000 записей.

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

EXPLAIN 
SELECT pm.partnum, pb.brand_name 
FROM products_main AS pm 
LEFT JOIN products_brands AS pb ON pm.id_brand=pb.id_brand 
ORDER BY pb.brand ASC 
LIMIT 0, 10 

Запрос возвращает этот план выполнения:

ID, SELECT_TYPE, TABLE, TYPE, POSSIBLE_KEYS, KEY, KEY_LEN , REF, ROWS, EXTRA 
1, SIMPLE, pm, range, PRIMARY, PRIMARY, 1, , 1000000, Using where; Using temporary; Using filesort 
1, SIMPLE, pb, ref, PRIMARY, PRIMARY, 4, demo.pm.id_pbrand, 1, 

Оптимизатор запросов MySQL показывает временную + FileSort в плане исполнения. Как я могу избежать этого?

«ЗЛО» находится в ORDER BY pb.brand ASC. Заказ на это внешнее поле, по-видимому, является узким местом.

Answer 1

Сначала попробуйте изменить свой индекс на products_brands стол. Удалите существующий на brand_name, и создать новый:

ALTER TABLE products_brands ADD INDEX newIdx (brand_name, id_brand) 

Затем таблица уже есть «orderedByBrandName» индекс с идентификаторами вам нужно для объединения, и вы можете попробовать:

EXPLAIN 
SELECT pb.brand_name, pm.partnum 
FROM products_brands AS pb 
    LEFT JOIN products_main AS pm ON pb.id_brand = pm.id_brand 
LIMIT 0, 10 

Обратите внимание, что я также изменил порядок таблиц в запросе, поэтому вы начинаете с маленького.

Answer 2

Прежде всего, я сомневаюсь в том, что использование внешнего соединения рассматривается как порядок, действующий на rhs, и NULL, введенный левым соединением, скорее всего, будет иметь хаос с ним.

Независимо от того, самый простой способ ускорения этого запроса был бы индексом покрытия на pb.id_brand и pb.brand. Это позволит упорядочивать оценку «using index» с условием объединения. Альтернативой является поиск некоторого способа уменьшить размер промежуточного результата, переданного в порядок.

Тем не менее, сочетание внешнего соединения, порядка и ограничений оставляет меня в недоумении, что именно вы запрашиваете, и если не может быть лучшего способа выражения самого запроса.

Answer 3

Попробуйте заменить соединение на подзапрос. Оптимизатор MySQL - отстой; подзапросы часто дают лучшую производительность, чем объединения.

Answer 4

Этот вопрос несколько устарел, но я нашел его, и так будут другие люди.

Mysql использует временные, если ORDER BY или GROUP BY содержит столбцы из таблиц, отличных от первой таблицы в очереди объединений.

Так что вам просто нужно иметь порядок соединения обращенный с помощью STRAIGHT_JOIN, чтобы обойти порядок изобретенного оптимизатора:

SELECT STRAIGHT_JOIN pm.partnum, pb.brand_name 
FROM products_brands AS pb 
RIGHT JOIN products_main AS pm ON pm.id_brand=pb.id_brand 
ORDER BY pb.brand ASC 
LIMIT 0, 10 

Также убедитесь, что max_heap_table_size И tmp_table_size переменными устанавливаются в ряд достаточно большим, чтобы сохранить Результаты:

SET global tmp_table_size=100000000; 
SET global max_heap_table_size=100000000; 

- 100 мегабайт в этом примере. Они также могут быть установлены в файле конфигурации my.cnf.