2012-06-08 2 views
1

Учитывая запрос приводится к виду:Регистрация производительности: Oracle против MySQL

select b.field1 
from table_a a 
    inner join table_b b on b.field1 = a.field1 
    left join table_c c on c.field1 = a.field1 
    left join table_d d on d.field1 = b.field1 
    left join table_e e on e.field1 = b.field6 
group by b.field1, 
     b.field2, 
     b.field3, 
     b.field4, 
     b.field5, 

     e.field2, 
     e.field3 
; 

с определенным количеством данных он работает в течение 20 секунд в Oracle. В Oracle ничего не индексируется. Мигрированный в MySQL запрос не хочет заканчиваться (выполняется за считанные минуты). Каждая область, о которой идет речь, индексируется в MySQL. Explain говорит, что все в порядке.

По-прежнему не работает, поля группировки получили индексы с несколькими столбцами. Еще ничего.

В чем может быть проблема, что по-прежнему существует большая утечка в производительности MySQL? Есть ли способ ускорить его?

+0

Не могли бы вы также подтвердить, что инфраструктура в обоих тестах одинакова? – Sebas

+0

Да, это то же самое. Кроме того, я помещаю поле в выборку, потому что в противном случае он выбросил ошибку в Oracle (Pl/SQL). Я просто хотел уменьшить запрос настолько, насколько мог. – user1433877

+0

мой друг не все характеристики идут с индексом, также идут двигатель, кеш, буфер и т. Д. – jcho360

ответ

8

Oracle способен делать хеш-соединения и объединяет соединения, MySQL - нет.

Поскольку ваши таблицы не фильтруются каким-либо образом, хэш-соединения были бы наиболее эффективным способом выполнения объединений, особенно если у вас нет индексов.

С вложенными циклами, даже если все поля объединения проиндексированы, MySQL необходимо выполнить поиск индекса по каждому значению из ведущей таблицы в цикле (каждый раз, начиная с начальной страницы индекса), а затем искать таблицу в извлеките запись, затем повторите ее для каждой объединенной таблицы. Это связано с множеством случайных запросов.

Хеш-соединение, с другой стороны, требует сканирования меньшей таблицы один раз (построение хеш-таблицы), а затем сканирование большего стола один раз (поиск построенной таблицы хэшей). Это предполагает последовательное сканирование, которое выполняется намного быстрее.

Кроме того, с вложенными циклами таблицу с левым соединением можно приводить в действие (проверять во внутреннем цикле), в то время как таблицы хеш-соединений с обеих сторон могут быть ведущими (отсканированными) или управляемыми (хэшируются, а затем выполняются поиск). Это также влияет на производительность.

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

+0

Есть ли способ достичь этого с помощью MySQL? – user1433877

+0

@ user1433877: достичь чего, хэш объединяется? № – Quassnoi

+0

+1 Но кроме таблиц хэша может быть способ сделать обходной путь? – user1433877

Смежные вопросы