|
|
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
В старых версиях FB (2.0, 2.1) насколько я знаю, нет автоматического обновления индексной статистики (во всяком случае у меня такое мнение сложилось). Из-за этого очень часто FB принимает неправильные решения по использованию индексов. Приходится очень часто в коде использовать приёмы "ORDER BY ID+0" либо уточнять план запроса после WHERE. Также из-за этого я не использую JOIN. Только LEFT JOIN. Подскажите, в последних версиях FB (3.x, 4.x) ситуация такая-же или разработчики FB что-нибудь улучшили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 09:10 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
статистика в трешке задействуется более интеллектуально, но пересчитывать ее время от времени все также ручками нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 09:54 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
DmSer, автоматическое обновление статистики планируется сделать в 4.0. Но оптимизатор в 2.5 и 3.0 менялся, причём в некоторых местах существенно. DmSerТакже из-за этого я не использую JOIN. Только LEFT JOIN. А вот это зря. Явные планы лучше не писать вообще никогда. +0 наше всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 09:58 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЯвные планы лучше не писать вообще никогда. +0 наше всё. Пару раз натыкался на случаи, когда индексы-то используются нужные, а вот порядок перебора таблиц всё-таки нежелательный. Но для вас это, возможно, было давно и неправда, на полуторке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 14:52 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
Старый плюшевый мишка, я это говорю с учётом апгрейда на будущие версии. План который нормально кушался на полуторке на 3.0 может давать ошибку. Хинты хотя бы не создают несовместимостей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 15:32 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЯвные планы лучше не писать вообще никогда. +0 наше всё. Вы это по поводу LEFT JOIN? К сожалению, в случае FB, я пришёл к такому варианту в результате собственного опыта, когда при обычном JOIN невозможно предсказать, в каком порядке будет производиться обход таблиц. Во многих случаях указание LEFT JOIN позволило решить проблемы производительности. Если Вы по поводу явного указания плана запроса "PLAN", то иногда возникают ситуации, когда +0 не помогает. Например есть индекс на поле TIME и есть второй индекс на поля USER_ID, TIME, у обоих индексов одинаковая статистика (конкретно я разбирался - было значение "0"). В итоге при запросе WHERE USER_ID=:id AND TIME BETWEEN :t1 AND :t2 СУБД (FB 2.0.7) решает, что нужно использовать первый индекс (а это замедление в сотни раз). С помощью "+0" такое не обойти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 15:33 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
DmSer, видишь ли. План это такая гадость которую начиная с 2.0 всегда надо писать целиком. Как только запрос чуть сложнее чем джойн из двух таблиц, написание плана становится занятием не тривиальным, а подчас и не возможным. Попробуй растолкуй оптимизатору рекурсивный запрос например. DmSerНапример есть индекс на поле TIME и есть второй индекс на поля USER_ID, TIME, у обоих индексов одинаковая статистика (конкретно я разбирался - было значение "0"). В итоге при запросе WHERE USER_ID=:id AND TIME BETWEEN :t1 AND :t2 СУБД (FB 2.0.7) решает, что нужно использовать первый индекс (а это замедление в сотни раз). С помощью "+0" такое не обойти. ну на 2.5 и 3.0 я с таким не сталкивался. Вы точно статистику пересчитывали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 15:43 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
DmSer, когда при обычном JOIN невозможно предсказать, в каком порядке будет производиться обход таблиц. Во многих случаях указание LEFT JOIN позволило решить проблемы производительности. и не надо предсказывать. оптимизатор ФБ нормально по кардинальности определяет порядок объединения таблиц. А если его принуждать явным left join, то если таблицы по данным перекосит, то потом будет с производительностью только хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 15:44 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
31.08.2018 15:32, Симонов Денис пишет: > План который нормально кушался на полуторке на 3.0 может давать ошибку. подтверждаю. > Хинты хотя бы не создают несовместимостей. это не хинты. это попытка нае... (нагнуть) оптимизатор стуча ему линейкой по пальцам. оптимизатор начинает пальцы отдёргивать и не всегда в той последовательности в какой хотелось бы наставнику с линейкой. тикет был про ораклячьи хинты, но у-вы. хватило бы одного /*+ ORDERED */ Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 16:00 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
31.08.2018 15:44, kdv пишет: > оптимизатор ФБ нормально по кардинальности определяет порядок объединения таблиц. вот не надо песен. и Оракл не всегда оптимальный порядок выбирает. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2018, 16:02 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
DmSerНапример есть индекс на поле TIME и есть второй индекс на поля USER_ID, TIME, у обоих индексов одинаковая статистика (конкретно я разбирался - было значение "0"). В итоге при запросе WHERE USER_ID=:id AND TIME BETWEEN :t1 AND :t2 СУБД (FB 2.0.7) решает, что нужно использовать первый индекс (а это замедление в сотни раз). С помощью "+0" такое не обойти. Почему не обойти? Разве не поможет WHERE USER_ID +0 =:id AND TIME BETWEEN :t1 AND :t2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 03:20 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
DmSerВы это по поводу LEFT JOIN? К сожалению, в случае FB, я пришёл к такому варианту в результате собственного опыта, когда при обычном JOIN невозможно предсказать, в каком порядке будет производиться обход таблиц. Во многих случаях указание LEFT JOIN позволило решить проблемы производительности. Возможно, ты натолкнулся на баг, связанный с TABLE LEFT JOIN TABLE2 INNER JOIN TABLE3. В моей практике в 99,9% случаев FB строит оптимальный план и отказываться ради 0,1% случаев от нормального написания запросов - перебор. Тормозящие запросы - видно сразу, а там уже подкрутить через LEFT JOIN или +0 не составляет проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 04:13 |
|
||
|
Обновление индексной статистики
|
|||
|---|---|---|---|
|
#18+
CyberMaxВозможно, ты натолкнулся на баг, связанный с TABLE LEFT JOIN TABLE2 INNER JOIN TABLE3. В моей практике в 99,9% случаев FB строит оптимальный план и отказываться ради 0,1% случаев от нормального написания запросов - перебор. Тормозящие запросы - видно сразу, а там уже подкрутить через LEFT JOIN или +0 не составляет проблемы. Нет, я не использую явный JOIN. Я указывал, что у обоих индексов статистика была = 0, в этом случае FB решал, что нужно брать индекс, который по одному полю, вместо индекса по двум полям (на самом деле 3 поля, но не думаю, что это принципиально). После пересчёта статистики всё заработало нормально, тут вопросов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2018, 13:07 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=39696306&tid=1560983]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 166ms |
| 0 / 0 |
