Много раз пытался разобраться с тем как нужно конструировать планы запросов, но так и нет полной картины, какая то каша... Хорошей документации на русском языке тоже не смог найти...
Знаю, что щас будете говорить, что мол в хорошо спроектированной базе не надо в ручную планы писать всё на автомате чётко работает, но иногда всё же нужно прописать план иначе запрос будет выполняться в разы медленнее!
Мой вопрос в том как же писать планы в ручную и как их анализировать? Если можно, приведите несколько примеров!
Вопрос не простой, а ответ ещё сложнее, но думаю общими усилиями можно пролить свет...
Планы и ещё раз планы...
проливать свет не надо. и на русский я 2 статьи по планам переводить не собираюсь, и даже если их кто то сделает, вряд ли помещу на сайт (вот такой я вредный). Почему? Потому:
перед тем как заняться ручным планированием надо
1. убедиться что статистика по индексам регулярно собирается (как? см. документацию).
2. убрать бесполезные индексы. т.е. те, в которых очень мало разных значений.
3. попробовать способы принудительного включения (where a >= 0) или выключения (where a +0 > x) индексов.
4. если запрос содержит явный outer join, попробовать переставить таблицы (и порядок join-ов) местами.
на этом этапе ручной план не потребуется в 95% случаев.
Кроме того, оптимизатор в FB постоянно умнеет, поэтому не факт что вручную прописанный план со временем окажется оптимальным.
Да, и еще, зачастую медленно выполняющийся запрос - это неумение разработчика писать запросы, собственно, или слишком вычурная организация данных. Это без личностей, просто очень часто встречается - делают where x in (select) вместо outer join, и еще много всяких несуразностей.
Т.е. лучше научиться писать один и тот же запрос (возвращающий одинаковый результат) по разному.
перед тем как заняться ручным планированием надо
1. убедиться что статистика по индексам регулярно собирается (как? см. документацию).
2. убрать бесполезные индексы. т.е. те, в которых очень мало разных значений.
3. попробовать способы принудительного включения (where a >= 0) или выключения (where a +0 > x) индексов.
4. если запрос содержит явный outer join, попробовать переставить таблицы (и порядок join-ов) местами.
на этом этапе ручной план не потребуется в 95% случаев.
Кроме того, оптимизатор в FB постоянно умнеет, поэтому не факт что вручную прописанный план со временем окажется оптимальным.
Да, и еще, зачастую медленно выполняющийся запрос - это неумение разработчика писать запросы, собственно, или слишком вычурная организация данных. Это без личностей, просто очень часто встречается - делают where x in (select) вместо outer join, и еще много всяких несуразностей.
Т.е. лучше научиться писать один и тот же запрос (возвращающий одинаковый результат) по разному.
Примерно такого ответа я и ожидал...
Обо всём этом я вкурсе. За всю мою не большую (3х летнюю) практику (с FB) мне пришлось всего 1 раз подставлять план вручную! Но насколько я помню, вы, уважаемый kdv, сами несколько раз использовали ручное планирование...
В одном из запросов у меня соединяется больше 10 таблиц, пробовал я этот запрос переписать разными способами и через join (с переменой мест "слагаемых") и через where table1.id=table2.id_table1 результат всё равно меня не устраивает! Спасла меня только явная (ручная) подстановка плана... Где я его взял, если не знаю как его писать? Заметил, что при добавлении в where условия типа name='вася', оптимизатор подставил другой план, при котором время выполнения сократилось в разы, я скопировал этот план и подставил в запрос без этого условия и, как ни странно, всё заработало
Но хотелось бы всё же понимать как составляется план и для его анализа и для ручной подстановки!
Обо всём этом я вкурсе. За всю мою не большую (3х летнюю) практику (с FB) мне пришлось всего 1 раз подставлять план вручную! Но насколько я помню, вы, уважаемый kdv, сами несколько раз использовали ручное планирование...
В одном из запросов у меня соединяется больше 10 таблиц, пробовал я этот запрос переписать разными способами и через join (с переменой мест "слагаемых") и через where table1.id=table2.id_table1 результат всё равно меня не устраивает! Спасла меня только явная (ручная) подстановка плана... Где я его взял, если не знаю как его писать? Заметил, что при добавлении в where условия типа name='вася', оптимизатор подставил другой план, при котором время выполнения сократилось в разы, я скопировал этот план и подставил в запрос без этого условия и, как ни странно, всё заработало
Но хотелось бы всё же понимать как составляется план и для его анализа и для ручной подстановки!
лично я не пишу планы руками. и вообще, написать план руками для запроса, с нуля, может наверное только человек пятнадцати пядей во лбу, или тот кто писал оптимизатор. Вот покрутить план подставляя-убирая использование индексов - да, еще можно. но как я сказал это можно делать и без корректировки плана.
Да, бывает план надо "прибить гвоздями" к запросу. но это не подразумевает, что план должен быть написан вручную
про то, как работает оптимизатор и в смысле формирования планов есть три статьи на
http://www.ibase.ru/develop.htm
в разделе "Оптимизация, ..."
одна на русском, две на английском. И они лежат там года четыре.
одну я пытался перевести, но понял, что занятие это бесполезное - во-первых, тяжелая терминология, а во-вторых - кому надо, прочитают и на английском... Вот такие пироги.
Да, бывает план надо "прибить гвоздями" к запросу. но это не подразумевает, что план должен быть написан вручную
про то, как работает оптимизатор и в смысле формирования планов есть три статьи на
http://www.ibase.ru/develop.htm
в разделе "Оптимизация, ..."
одна на русском, две на английском. И они лежат там года четыре.
одну я пытался перевести, но понял, что занятие это бесполезное - во-первых, тяжелая терминология, а во-вторых - кому надо, прочитают и на английском... Вот такие пироги.
Все статьи по указанному адресу http://www.ibase.ru/develop.htm я прочитал когда только начинал работать с FB (правда только те, что на русском языке). Некоторые из них я перечитывал много раз! В своё время эти статьи мне очень помогли, за что вам огромнейшее спасибо!
Но для меня вопрос "планового хозяйства" так и остался не до конца освещённым... Может и правда пора прочитать статьи на английском...
В любом случае Вам большое спасибо! Удачи и с прошедшим юбилеем
Но для меня вопрос "планового хозяйства" так и остался не до конца освещённым... Может и правда пора прочитать статьи на английском...
В любом случае Вам большое спасибо! Удачи и с прошедшим юбилеем
а я не говорил о примитивных выборках, например индексных. Я про штук 5 объединенных таблиц, с агрегатами и т.п.Merlin писал(а):Льстецkdv писал(а): и вообще, написать план руками для запроса, с нуля, может наверное только человек пятнадцати пядей во лбу
вообще конечно это можно делать, т.е. писать руками запросы. но по-моему это очень нудно. Гораздо проще сначала получить запрос, а потом его "покрутить". а если запрос содержит явные left/right join, то тут вообще все просто - выстраиваешь таблицы, и оптимизатор генерит как раз такой план.
-
Alexey Kovyazin
- Сообщения: 15
- Зарегистрирован: 25 окт 2004, 19:13