Форум: "Базы";
Текущий архив: 2002.04.25;
Скачать: [xml.tar.bz2];
ВнизОптимизация SQL запроса Найти похожие ветки
← →
DiggerAbstract (2002-04-03 10:55) [0]предлагаю небольшое обсуждение: некоторые правила которые вы применяете для оптимизации SQL запросов!
← →
Alexandr (2002-04-03 10:59) [1]зависит от сервера
← →
DiggerAbstract (2002-04-03 11:00) [2]можешь указать тип сервера
← →
Alexandr (2002-04-03 11:06) [3]а нафиг это тебе.
На эту тему книги писать можно, при том что для каждого сервера свою.
Это целое искусство
← →
DiggerAbstract (2002-04-03 11:16) [4]ну скажем так - общие концепции построения запроса не привязаваются к к.-л. серверу.
например такое как: не применят вложенные селекты в области перечисления полей(очень сильно тормозит процесс) или например:
select *
from table1 t1
join table2 t2 on t1.pole1=t2.pole1
where t1.pole2=...
и др.
select *
from (select * from table1 where pole2=...) t1
join table2 t2 on t1.pole1=t2.pole1
второй запрос будет работать быстрее, т. к. мы обрубаем выборку раньше.
и т. п. вещи
← →
Johnmen (2002-04-03 11:23) [5]> select *
> from (select * from table1 where pole2=...) t1
> join table2 t2 on t1.pole1=t2.pole1
Зависит от сервера - тебе же уже сказали...
← →
DiggerAbstract (2002-04-03 11:30) [6]повторю еще разок - "общие концепции построения запроса не привязаваются к к.-л. серверу".
← →
Alexandr (2002-04-03 11:40) [7]наверное, нету общих концепций оптимизации SQL запросов.
← →
Sergey13 (2002-04-03 11:54) [8]Я стараюсь писать сложные запросы постепенно, т.е. цеплять каждую таблицу отдельно, и после каждого "прицепа" смотреть план выполнения. Обычно помогает.
← →
Reindeer Moss Eater (2002-04-03 12:26) [9]Дорогой план не обязательно означает долгое выполнение запроса
← →
Delirium (2002-04-03 12:45) [10]Ну в общем-то различные концепции оптимизации по своей сути едины : выигрываем в скорости - проигрываем в объёме и на оборот. Так при активном использовании временных таблиц (и временных идексов) можно получать результат отличный по скорости исполнения в десятки раз от классического подхода (единый select со множеством join-ов и вложенных запросов). И при этом использовать во много раз больше памяти и дискового пространства сервера. Так что обсуждать тут особо нечего, у каждого сервера БД подходы и методы свои, IMHO.
← →
wicked (2002-04-03 13:55) [11]по теме
для mssql характерно, что предложения с exists выполняются иногда в десятки раз быстрее, чем предложения с in... правда, с соответствующей перестройкой запроса... ;)
а вообще, насколько я понял, в оптимизации скорости запросов сами запросы играют не очень большую роль... многое зависит как от сервера БД, так и от его настроек, и от организации ("нормальности") данных... плюс еще и правильное, сбалансированное индексирование...
← →
Alexandr (2002-04-03 13:56) [12]ага денормализация
← →
Nikolay M. (2002-04-03 19:03) [13]http://valdis.narod.ru/sql/les17.htm#op_setup
- здесь написано много об "общем", но не соглашусь, что все пункты верны для разных СУБД. Все зависит от оптимизатора запросов и если идет требуется оптимизация на уровне построения запросов, то, наверное, есть смысл воспользоваться анализатором запросов (если таковой есть. В MySQL, к примеру, можно посмотреть какие индексы будут использоваться и т.д.) и ставить эксперименты.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.04.25;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.005 c