none
оптимизация запроса - проблема RRS feed

  • Вопрос

  • Привет всем :)

     

    Подскажите как оптимизировать такой запрос

    Я примерно полагаю, что нужно поменьше ссылок на таблицы и выражение where нужно или только к like привести, но может я не прав... Но я не нашел как использовать like в моем случае :( Подскажите плз

     

     

    SELECT o.* FROM Products o

    INNER JOIN Catalog ca ON o.CatalogID = ca.CatalogID

    WHERE product_title like ‘%Daily%’ AND  (c. Description = ‘Milk FA’ 

                                               OR c. Description = ‘Milk DG5’)

     

     

    Заранее спасибо за полезные комментарии

    • Перемещено SachinW 2 октября 2010 г. 0:14 MSDN Forums Consolidation (От:SQL Server для разработчиков)
    10 августа 2010 г. 19:46

Ответы

Все ответы

  • В данном запросе использование LIKE действительно неоптимально. Ставя вререди паттерна % вы лишаете оптимизатор возможности использовать индекс и SQL сервер будет делать сканирование таблицы (например %Daily, %Weekly и т.п.). Как вариант конечно еще использовать полнотекстовый поиск на этом столбце, если для вас подходит такое решение.
    • Предложено в качестве ответа Naomi N 11 августа 2010 г. 4:47
    • Отменено предложение в качестве ответа andrewmorozov 11 августа 2010 г. 18:39
    • Предложено в качестве ответа Naomi N 7 сентября 2010 г. 20:36
    11 августа 2010 г. 4:11
  • Ставя вререди паттерна % вы лишаете оптимизатор возможности использовать индекс и SQL сервер будет делать сканирование таблицы
    Всё-таки интересно сперва услышать версию сиквела и какие имеются индексы, ибо сканирование возможно будет и не по таблице, а по индексу (http://dev.net.ua/blogs/def1983/archive/2007/09/10/SQL-Server-2005_3A00_-index-seek-_3F0440043804_-_2620_-like-_27002500_abc_25002700_.aspx)
    http://www.t-sql.ru
    • Предложено в качестве ответа Naomi N 5 сентября 2010 г. 4:02
    • Помечено в качестве ответа I.Vorontsov 6 сентября 2010 г. 5:10
    11 августа 2010 г. 13:45
    Модератор
  • таблица Products имеет такое свойство PK Clustered

    Для справки интересно, а что если бы были индексы?

    А как быть с вот этим (SELECT o.* FROM Products o) выражением? ссылка на метку это оптимально или не очень?

    То есть нужно свести такой запрос к везде логическому "="  и все? Тогда получится целых 3 выражения с оператором "=". Это оптимально?

     

     

    • Изменено andrewmorozov 11 августа 2010 г. 19:15
    11 августа 2010 г. 18:39
  • А сиквел 2005 :)
    11 августа 2010 г. 18:40
  • Я бы посоветовал вам смотреть на план запроса. Сразу увидете где и что  занимает больше всего времени. Соответственно попробуете разные варианты и увидите разницу.

    20 августа 2010 г. 6:23
  • Если размер таблицы очень большой или ожидается что он вернет много данных, то лучше избегать в выражении "OR" вместо него лучше использовать объединение с помощью UNION или UNION ALL, так будет быстрее, ну и  как было сказано ранее, процент перед %Daily  лучше убрать если по полю product_title есть индекс, пример:

    SELECT o.* FROM Products o

    INNER JOIN Catalog ca ON o.CatalogID = ca.CatalogID

    WHERE product_title like ‘%Daily%’ AND c. Description = ‘Milk FA’ 

    UNION ALL

    SELECT o.* FROM Products o

    INNER JOIN Catalog ca ON o.CatalogID = ca.CatalogID

    WHERE product_title like ‘%Daily%’ AND c. Description = ‘Milk DG5’ 

    • Помечено в качестве ответа I.Vorontsov 27 августа 2010 г. 12:59
    • Снята пометка об ответе andrewmorozov 4 сентября 2010 г. 20:52
    • Предложено в качестве ответа Naomi N 7 сентября 2010 г. 20:37
    21 августа 2010 г. 18:40
  • Я читал где-то, что вызов таблицы через ссылку на БД - это не очень оптимально :(

    Но может это несущественно?

    А вот насчет UNION ALL, то это достаточно интересный подход если может заменить выражение, как:

    (c. Description = ‘Milk FA’ OR c. Description = ‘Milk DG5’)

    Или я тут не совсем так понял идею?

    4 сентября 2010 г. 20:57
  • Я бы посоветовал вам смотреть на план запроса. Сразу увидете где и что  занимает больше всего времени. Соответственно попробуете разные варианты и увидите разницу.


    Вот это здорово конечно, но только БД теоретическая :) Точнее сказать - интересно заранее написать с учетом большой нагруженности в будущем.

    Размер где-то до 200 000...

    4 сентября 2010 г. 20:59
  • Я бы посоветовал вам смотреть на план запроса. Сразу увидете где и что  занимает больше всего времени. Соответственно попробуете разные варианты и увидите разницу.


    Вот это здорово конечно, но только БД теоретическая :) Точнее сказать - интересно заранее написать с учетом большой нагруженности в будущем.

    Размер где-то до 200 000...


    Поэтому аналзироватьплан нужно на боевой системе, либо поднимать полигон с БД преближенной максимально к реальной, иначе вы не сможете однозначно оценить
    http://www.t-sql.ru
    • Предложено в качестве ответа Naomi N 7 сентября 2010 г. 20:37
    5 сентября 2010 г. 5:21
    Модератор
  • Ну так сымитируйте эту большую нагруженность. К тому же, большая нагруженность бывает совершенно разного рода. Кто кроме вас может подумать на эту тему заранее?
    • Предложено в качестве ответа Naomi N 7 сентября 2010 г. 20:37
    5 сентября 2010 г. 7:41
  • Ну так сымитируйте эту большую нагруженность. К тому же, большая нагруженность бывает совершенно разного рода. Кто кроме вас может подумать на эту тему заранее?

    Нужно будет ещё поразмыслить ;) Стрессовая утилита думаю будет в помощь...
    7 сентября 2010 г. 19:41
  • c.Description IN ('Milk FA','Milk DG55')
    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    7 сентября 2010 г. 20:38
  • c.Description IN ('Milk FA','Milk DG55')
    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog


    Это в смысле, чтобы 2 в одном было ? А это оптимальный способ с учетом наличия индексов например?

    Все равно - спасибо. Функция хорошая :)

    8 сентября 2010 г. 17:10
  • Optimal'nyj, osobenno, esli est' index on Description field.

    http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/4ca39765-6521-4dec-aec1-373b1adf0be7


    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    8 сентября 2010 г. 17:36