2017-02-09 9 views
0

Я хочу заказать результат соединения между 4 таблицами - Будет ли создание индекса для порядка по столбцу (b.SITE_ID) улучшить производительность запросов?делает индекс улучшает производительность при сортировке результатов объединения

SELECT b.SERVICE_ID, b.ATT_ID, b.SITE_ID, b.ATT_VALUE, c.KEY_NAME, d.NAME as account_name 
FROM SITE_ATTRIBUTES a , SF_SITE_ATTRIBUTES b, ATTRIBUTE_DEF c,SF_SITE_MASTER d 
WHERE a.SERVICE_ID=b.SERVICE_ID 
    and b.SERVICE_ID=c.SERVICE_ID 
    and b.SERVICE_ID=d.SERVICE_ID 
    and [email protected]_id COLLATE utf8_unicode_ci 
    and b.ATT_ID= c.ID 
    and b.ATT_ID= a.ATT_DEF 
    and a.SITE=b.SITE_id 
    and b.SITE_ID = d.ID 
    and a.value != b.att_value 
    and b.att_value is not null 
ORDER BY b.SITE_ID 

Думая, что это не будет, так как порядок происходит через посредника присоединяется результирующий набор ...

+0

думаю есть. Но вы должны попытаться проверить анализ объяснений. Вопросы производительности должны включать «EXPLAIN ANALYZE» и некоторую информацию о размере таблицы, индексе, текущем времени, времени ожидания и т. Д. «Slow» - относительный термин, и нам нужно реальное значение для сравнения. \t \t [** MySQL **] (http://dba.stackexchange.com/questions/15371/how-do-i-get-the-execution-plan-for-a-view) –

+0

Прочтите это DBA Stack Exchange вопрос: http://dba.stackexchange.com/questions/11031/order-by-column-should-have-index-or-not ... ответ может быть, возможно, да –

+0

И вы действительно должны прочитать это. Поощряйте использование эксплицитного 'JOIN' sintaxis, Аарон Бертран написал хорошую статью [Плохие привычки пинать: использование JOIN в старом стиле] (http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/08/bad -habits-to-kick-using-old-style-joins.aspx) об этом. –

ответ

0

[email protected]_id COLLATE utf8_unicode_ci неэффективно, так как это требует изменения сортировки на лету. Измените его так, SERVICE_ID объявлен COLLATE tf8_unicode_ciи ваше соединение использует эту сортировку. Тогда ...

INDEX(SERVICE_ID, SITE_ID) 

, вероятно, будет лучше -

  1. Фильтр по SERVICE_ID;
  2. Избегать сортировки: SITE_ID.

Остальная часть фильтрации (!= и NOT NULL) неизбежна путем индексирования.

Просто INDEX(SITE_ID), вероятно, не так хорошо подходит для этот запрос.