|
16.03.2010, 16:33 | #1 |
Участник
|
Абсолютно серьезно. Много таких мест переделал, когда возникали тормоза - менял местами поля в условии. Я сугубо практик, не теоретик. База медленно работает тогда, когда программисты не следят за тем, что у них в условии "where" написано. По более уникальному полю SQL-сервер сразу отсекает кучу ненужной информации.
В приведенном мною примере сервер быстро найдет складские проводки по коду журнала - их всего несколько десятков штук, а затем из этих нескольких десятков проводок выберет те, у которых тип - "Перенос". А если написать запрос наоборот, то сервер сначала будет искать все проводки с типом "Перенос" - их могут быть миллиноны. |
|
16.03.2010, 16:51 | #2 |
Участник
|
|
|
16.03.2010, 17:53 | #3 |
Участник
|
Вы наверное испытывате желание подловить меня на чем-то? То, что я предлагаю, работает лишь на сложных запросах. Найти стандартный пример я вам не могу, т.к. это зависит от многих условий, и на разных базах один и тот же запрос будет работать очень быстро или очень медленно.
Вот недавно оптимизированный в моей базе запрос, который зависал. Запрос до оптимизации PHP код:
Запрос после оптимизации PHP код:
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
16.03.2010, 17:57 | #4 |
Участник
|
И мне непонятно желание подкольнуть меня. Неужто я что-то вредное предлагаю? Неужто внимательное написание запросов - это вредный совет? И неужто для вас так важно, вы так хотите не соблюдать порядок полей в условиях?
Последний раз редактировалось Ace of Database; 16.03.2010 в 18:01. |
|
16.03.2010, 18:00 | #5 |
Участник
|
Намеренно оставил в комментариях кода //group by TableId .
Просто у нас тут тоже были спорщики, которые утверждали, что exists join тормозит. И пытались ускорить путем устранения exist join'а. Пока не переставил местами поля в условиях отбора, ничего не помогало |
|
16.03.2010, 18:01 | #6 |
Участник
|
Цитата:
Если все именно так и есть как вы говорите, то я сильно разочаруюсь в MS SQL |
|
16.03.2010, 18:49 | #7 |
Участник
|
Цитата:
P.S.: А как вы представляете себе соблюдение 'оптимальной' последовательности условий при конструировании запроса при помощи Query? |
|
16.03.2010, 19:07 | #8 |
Участник
|
Цитата:
Сообщение от S.Kuskov
Ничего личного. Стратегия оптимизации логична и ясна. Просто необходимость проделывать её вручную ствится под сомнение. Нужно подобрать хороший пример и провести исследование данного вопроса.
P.S.: А как вы представляете себе соблюдение 'оптимальной' последовательности условий при конструировании запроса при помощи Query? |
|
16.03.2010, 19:21 | #9 |
Участник
|
Согласен, с Query есть свои проблемы, но при желании их можно обойти. Помогите с Query
|
|
17.03.2010, 14:54 | #10 |
Участник
|
Первые два пункта "теории" разве не соответствуют взглядам на принципы оптимизации БД?
А 3-й и 4-й пункт кому-то наносят вред? PHP код:
|
|
17.03.2010, 15:04 | #11 |
Administrator
|
Цитата:
Вреда они не наносят. Но вот приносят ли пользу... Об этом и обсуждение
__________________
Возможно сделать все. Вопрос времени |
|
17.03.2010, 15:34 | #12 |
Участник
|
Цитата:
PHP код:
PHP код:
PHP код:
PHP код:
|
|
16.03.2010, 18:48 | #13 |
Участник
|
|
|
17.03.2010, 09:09 | #14 |
Участник
|
Цитата:
Сообщение от Ace of Database
Вы наверное испытывате желание подловить меня на чем-то? То, что я предлагаю, работает лишь на сложных запросах. Найти стандартный пример я вам не могу, т.к. это зависит от многих условий, и на разных базах один и тот же запрос будет работать очень быстро или очень медленно.
- устаревшая статистика - устаревший план (из за использования placeholders) и что-то дополнительное, что в запрос вставляет аксапта. Если в следующий раз встретится, не могли бы вы привести SQL, который уходит на сервер и план запроса? |
|
Теги |
index hint, sql server, оптимизация |
|
Похожие темы | ||||
Тема | Ответов | |||
Параметры запросов БД | 3 | |||
Владельцы таблиц в БД аксапты | 11 | |||
Оптимизация запросов | 6 | |||
Оптимизация запросов | 3 | |||
Просмотр SQL запросов к БД с помощью файла Log | 3 |
|