Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
Читаю "Настройка SQL для профессионалов", Дэна Тоу, уже больше половины прочёл, по сути, он предлагает эдакий научный способ определить, какие фильтры лучше, и отталкиваясь от этого, настраивать план выполнения запросов. Интуитивно ведь итак каждый оптимизирует именно таким способом. А уж если структуру таблиц БД знаешь вдоль и поперёк, то опять же можешь без всяких вычислений прикинуть, какой порядок будет лучше. Ну ничего, дочитаю книгу, попробую взять один из тормозных запросов с кучей таблиц пооптимизировать по его методике. Есть у кого-то положительный опыт, использования этой книжки?

--
Следующие на очереди будут
"Оракл, оптимизация производительности" Миллсап и Хольт.
"Оракл, основы стоимостной оптимизации" Льюис.
29 окт 12, 15:54    [13391899]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
Добрый Э - Эх
Guest
Дэн Тоу - это кто? В Оракле про такого не знают...
29 окт 12, 19:36    [13393176]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
-2-
Member

Откуда:
Сообщений: 15330
XDiaBLo
какой порядок будет лучше
а вы друзья как ни садитесь,
на оптимальность не годитесь
29 окт 12, 19:55    [13393268]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
ksv55
Member

Откуда:
Сообщений: 93
XDiaBLo,
Книга "Настройка SQL для профессионалов", Дэна Тоу неплохая, имеет ряд хороших методик, но содержит ряд ошибок.

Например, его конструкции вида T1.Key3_id+0*T2.Key2_id=T3.Key3_id, которые используются для отключения соединения в неправильном порядке заодно отключают и индекс по полю T1.Key3_id и т.п.
Так что для начинающего читать ее опасно.

Вначале прочитайте официальную Ораклячью документацию Performance Tuning Guide
Часть 4. Optimizing SQL Statements.
29 окт 12, 20:11    [13393323]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
Добрый Э - Эх
Дэн Тоу - это кто? В Оракле про такого не знают...

Так он типа претендует на универсальную оптимизацию под любую СУБД.
29 окт 12, 21:33    [13393539]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
ksv55
XDiaBLo,
Книга "Настройка SQL для профессионалов", Дэна Тоу неплохая, имеет ряд хороших методик, но содержит ряд ошибок.

Например, его конструкции вида T1.Key3_id+0*T2.Key2_id=T3.Key3_id, которые используются для отключения соединения в неправильном порядке заодно отключают и индекс по полю T1.Key3_id и т.п.
Так что для начинающего читать ее опасно.

Вначале прочитайте официальную Ораклячью документацию Performance Tuning Guide
Часть 4. Optimizing SQL Statements.

Ну так я такие моменты на практике проверяю, смотрю план выполнения, который Оракл показывает.
29 окт 12, 21:34    [13393542]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
Добрый Э - Эх
Guest
XDiaBLo
Так он типа претендует на универсальную оптимизацию под любую СУБД.
В том-то и дело, что "идеальный газ", "абсолютно черное тело", "температура абсолютного нуля" и прочие "сферические кони в вакууме" - это всего лишь физические абстракции, не имеющие ничего общего с реальной жизнью. Так же и идеальная СУБД - её не существует. Общих рекомендаций быть не может.
Что говорить за кросс-СУБД-шность советов по оптимизации, если даже в рамках оракла поведение оптимизатора меняется не только от версии к версии, но и от релиза к релизу внутри версии, и даже - от патча к патчу. Самый простой пример - встроенные представления. Нетрудно отследить на их примере эволюцию оптимизатора и, как следствие, подход разработчиков к написанию и оптимизации кода.
30 окт 12, 05:21    [13394249]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
Добрый Э - Эх
XDiaBLo
Так он типа претендует на универсальную оптимизацию под любую СУБД.
В том-то и дело, что "идеальный газ", "абсолютно черное тело", "температура абсолютного нуля" и прочие "сферические кони в вакууме" - это всего лишь физические абстракции, не имеющие ничего общего с реальной жизнью. Так же и идеальная СУБД - её не существует. Общих рекомендаций быть не может.
Что говорить за кросс-СУБД-шность советов по оптимизации, если даже в рамках оракла поведение оптимизатора меняется не только от версии к версии, но и от релиза к релизу внутри версии, и даже - от патча к патчу. Самый простой пример - встроенные представления. Нетрудно отследить на их примере эволюцию оптимизатора и, как следствие, подход разработчиков к написанию и оптимизации кода.

Это всё понятно, но независимо от СУБД, всё же некоторые моменты вполне даже универсальны, как например меньшее количество считываемых строк одной таблицы, если её подключить после другой, чем если бы её считывали до той, другой.
30 окт 12, 06:39    [13394274]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
XDiaBLo
Это всё понятно, но независимо от СУБД, всё же некоторые моменты вполне даже универсальны, как например меньшее количество считываемых строк одной таблицы, если её подключить после другой, чем если бы её считывали до той, другой.
За счет чего меньшее?
30 окт 12, 06:50    [13394280]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
wurdu
XDiaBLo
Это всё понятно, но независимо от СУБД, всё же некоторые моменты вполне даже универсальны, как например меньшее количество считываемых строк одной таблицы, если её подключить после другой, чем если бы её считывали до той, другой.
За счет чего меньшее?

Как за счёт чего? За счёт того, что оно уже отфильтровалось в другой таблице, с которой связка по ключу идёт. А по крайней мере в той БД с которой я работаю, внешние ключи в некоторых таблицах проиндексированы, соответственно соединение может нормально идти в любом направлении, поэтому возможно следует отфильтровать сначала большую таблицу, если в ней фильтр намного лучше.
30 окт 12, 07:09    [13394292]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
XDiaBLo
wurdu
пропущено...
За счет чего меньшее?

Как за счёт чего? За счёт того, что оно уже отфильтровалось в другой таблице, с которой связка по ключу идёт. А по крайней мере в той БД с которой я работаю, внешние ключи в некоторых таблицах проиндексированы, соответственно соединение может нормально идти в любом направлении, поэтому возможно следует отфильтровать сначала большую таблицу, если в ней фильтр намного лучше.
Так этот момент не является универсальным, а просто частный случай. К примеру:
SQL> create table tst as select mod(rownum,100) rn,mod(rownum,100) rn2 from dual connect by level <= 1000000;

Table created.

SQL> create table tst2 as select rownum rn from dual connect by level <= 100;

Table created.

SQL> set autotrace traceonly explain

SQL> create index idx_tst on tst(rn2);

Index created.

SQL> select  * from tst a , tst2 b where a.rn = b.rn and a.rn2 = 1;

Execution Plan
----------------------------------------------------------
Plan hash value: 3245686012

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 10061 |   383K|   482   (5)| 00:00:03 |
|*  1 |  HASH JOIN         |      | 10061 |   383K|   482   (5)| 00:00:03 |
|   2 |   TABLE ACCESS FULL| TST2 |   100 |  1300 |     2   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| TST  | 10061 |   255K|   479   (4)| 00:00:03 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("A"."RN"="B"."RN")
   3 - filter("A"."RN2"=1)
   
Как видим, несмотря на filter на большой таблице, все равно выгодней строить хэш по маленькой (не принципиально, но нем не менее). Ну и "меньшее количество считываемых строк одной таблицы" - вообще не применимо, т.к. считываем в любом случае все строки.
30 окт 12, 07:31    [13394311]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
ksv55
Member

Откуда:
Сообщений: 93
XDiaBLo,

Основной метод описанный в этой книге - идти от по цепочке наилучших селективностей и соединяться оптимальными методами в общем случае правилен, но он не учитывает много особенностей.

Попробуйте создать простейшую цепочку из трех таблиц A,B,C, где таблицы А,С вида
create table A as select rowid id, rpad(rowid,80) info from dual connect by level<=100000; --упорядочена
create table C as select * from A order by dbms_random.value; -- очень неупорядочена
Таблица В - связь. Создайте индексы по ключам. Соберите статистику.

Сделайте фильтр по С в два раза более селективным фильтра по А.
Посмотрите планы Оракла и статистику выполнения при разных значениях селективности и сравните с книгой.
30 окт 12, 07:38    [13394316]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
wurdu
Как видим, несмотря на filter на большой таблице, все равно выгодней строить хэш по маленькой (не принципиально, но нем не менее). Ну и "меньшее количество считываемых строк одной таблицы" - вообще не применимо, т.к. считываем в любом случае все строки.

Ты что-то накосячил просто.
30 окт 12, 07:44    [13394325]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
ksv55
XDiaBLo,

Основной метод описанный в этой книге - идти от по цепочке наилучших селективностей и соединяться оптимальными методами в общем случае правилен, но он не учитывает много особенностей.

Попробуйте создать простейшую цепочку из трех таблиц A,B,C, где таблицы А,С вида
create table A as select rowid id, rpad(rowid,80) info from dual connect by level<=100000; --упорядочена
create table C as select * from A order by dbms_random.value; -- очень неупорядочена
Таблица В - связь. Создайте индексы по ключам. Соберите статистику.

Сделайте фильтр по С в два раза более селективным фильтра по А.
Посмотрите планы Оракла и статистику выполнения при разных значениях селективности и сравните с книгой.

Я не буду ничего подобного делать, я лучше дочитаю книгу, и на практике проверю, на имеющейся в наличии БД, так как к чему эти абстрактные непонятные тестовые БД, если есть гигантская действующая БД? К тому же моя восьмилетняя практика показывает, что вообще-то Тоу прав. Только в том-то и дело, что его книга малополезна как раз поэтому. Потому-что я уже на практике всё это узнал, что он там описывает, только без лишних вычислений селективности, так как работая с этой БД много лет, я уже вдоль и поперёк эти селективности интуитивно знаю.
30 окт 12, 07:48    [13394333]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
XDiaBLo
wurdu
Как видим, несмотря на filter на большой таблице, все равно выгодней строить хэш по маленькой (не принципиально, но нем не менее). Ну и "меньшее количество считываемых строк одной таблицы" - вообще не применимо, т.к. считываем в любом случае все строки.

Ты что-то накосячил просто.
Это ты тоже интуитивно понял?
30 окт 12, 07:53    [13394344]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
wurdu
XDiaBLo
пропущено...

Ты что-то накосячил просто.
Это ты тоже интуитивно понял?

С индексами косяк.
30 окт 12, 07:54    [13394345]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
XDiaBLo
wurdu
пропущено...
Это ты тоже интуитивно понял?

С индексами косяк.
Какой?
30 окт 12, 07:56    [13394349]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
wurdu
XDiaBLo
пропущено...

С индексами косяк.
Какой?

Присмотрелся. Всё норм у тебя, просто это не тот случай.
30 окт 12, 07:56    [13394352]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
ksv55
XDiaBLo,
Книга "Настройка SQL для профессионалов", Дэна Тоу неплохая, имеет ряд хороших методик, но содержит ряд ошибок.

Например, его конструкции вида T1.Key3_id+0*T2.Key2_id=T3.Key3_id, которые используются для отключения соединения в неправильном порядке заодно отключают и индекс по полю T1.Key3_id и т.п.
Так что для начинающего читать ее опасно.

Вначале прочитайте официальную Ораклячью документацию Performance Tuning Guide
Часть 4. Optimizing SQL Statements.



Я хочу только отметить, что оптимизаторы — штука очень тонкая, и в книге возможно есть завязки на конкретную версию субд, т.е. это не обязательно так уж сразу и ошибка.
30 окт 12, 10:30    [13394974]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
MasterZiv
ksv55
XDiaBLo,
Книга "Настройка SQL для профессионалов", Дэна Тоу неплохая, имеет ряд хороших методик, но содержит ряд ошибок.

Например, его конструкции вида T1.Key3_id+0*T2.Key2_id=T3.Key3_id, которые используются для отключения соединения в неправильном порядке заодно отключают и индекс по полю T1.Key3_id и т.п.
Так что для начинающего читать ее опасно.

Вначале прочитайте официальную Ораклячью документацию Performance Tuning Guide
Часть 4. Optimizing SQL Statements.



Я хочу только отметить, что оптимизаторы — штука очень тонкая, и в книге возможно есть завязки на конкретную версию субд, т.е. это не обязательно так уж сразу и ошибка.

Так я и говорю не ошибка, сам пользовался, работает.
30 окт 12, 10:34    [13394993]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
AmKad
Member

Откуда:
Сообщений: 5222
XDiaBLo
Ты что-то накосячил просто.
Ха-ха). Поржал.
30 окт 12, 10:35    [13395002]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
XDiaBLo
Добрый Э - Эх
пропущено...
В том-то и дело, что "идеальный газ", "абсолютно черное тело", "температура абсолютного нуля" и прочие "сферические кони в вакууме" - это всего лишь физические абстракции, не имеющие ничего общего с реальной жизнью. Так же и идеальная СУБД - её не существует. Общих рекомендаций быть не может.
Что говорить за кросс-СУБД-шность советов по оптимизации, если даже в рамках оракла поведение оптимизатора меняется не только от версии к версии, но и от релиза к релизу внутри версии, и даже - от патча к патчу. Самый простой пример - встроенные представления. Нетрудно отследить на их примере эволюцию оптимизатора и, как следствие, подход разработчиков к написанию и оптимизации кода.

Это всё понятно, но независимо от СУБД, всё же некоторые моменты вполне даже универсальны, как например меньшее количество считываемых строк одной таблицы, если её подключить после другой, чем если бы её считывали до той, другой.


Ага, или построение по таблице hash индекса для последующего hash join и как следствие запуск запроса в космос вместо лошадиной поездки на велосипеде...

Это очень все сильно зависит от субд.

Конечно, общие моменты безусловно есть, но специфики конкретной субд очень много.

Например, оптимизация для оракла — это одно, а для модных нынче базовых структур таблиц на кластерных индексах — немного другое.
30 окт 12, 10:38    [13395018]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
AmKad
XDiaBLo
Ты что-то накосячил просто.
Ха-ха). Поржал.

Накосячил он в том, что ситуация не та.
30 окт 12, 10:38    [13395020]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
ten
Member

Откуда: Екатеринбург
Сообщений: 1672
XDiaBLo
Накосячил он в том, что ситуация не та.

Как сказал один умный человек:
"Если факты противоречат моей теории, тем хуже для фактов!"
30 окт 12, 10:44    [13395050]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация SQL  [new]
XDiaBLo
Member

Откуда: Екатеринбург
Сообщений: 71782
MasterZiv
XDiaBLo
пропущено...

Это всё понятно, но независимо от СУБД, всё же некоторые моменты вполне даже универсальны, как например меньшее количество считываемых строк одной таблицы, если её подключить после другой, чем если бы её считывали до той, другой.


Ага, или построение по таблице hash индекса для последующего hash join и как следствие запуск запроса в космос вместо лошадиной поездки на велосипеде...

Это очень все сильно зависит от субд.

Конечно, общие моменты безусловно есть, но специфики конкретной субд очень много.

Например, оптимизация для оракла — это одно, а для модных нынче базовых структур таблиц на кластерных индексах — немного другое.

Какой нафиг хэш джойн, Тоу пропагандист вложенных циклов, говорит хэш вообще редко полезен. Посмотрим, получится ли у меня хоть что-то по его советам заоптимизировать. Я пока тоже довольно скептически отношусь, но энтузиазма ещё немного остаётся, есть надежда, и несколько жутко тормозных запросов на примете.
30 окт 12, 10:44    [13395053]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить