|
|
|
IQ и join indexes
|
|||
|---|---|---|---|
|
#18+
Небольшой вопрос по индексам. Есть в ИК мастер и чайлд таблица. Часто по ним делается джойн - сделал джоин индекс - запросы стали летать. НО! В БД ночью делается загрузка платежей, принятых, либо измененных, за вчера-позавчера. И вновь пришедшие данные в таблице сначала удаляются (если они есть по ПК), а затем инсертятся. Данные из ASE забираю как советовал moris через insert location - все летает на ура. Раньше заливка данных за 2 дня занимала минут 10-15. После построения джоин индексов - не могу дождаться! Вчера через пару часов отрубил выполнение..... Что может быть? И как бороться? Или не использовать джоин индексы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 11:59 |
|
||
|
IQ и join indexes
|
|||
|---|---|---|---|
|
#18+
Добрый день. Я бы рекомендовал использовать join индексы только в самом крайнем случае. Если есть проблемы с производительностью, то лучше подумать о модификации модели данных в сторону денормализации. Эффект будет больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 15:46 |
|
||
|
IQ и join indexes
|
|||
|---|---|---|---|
|
#18+
А в чем проблемы? Ктото уже работал с ними? Просто их построение улучшило выборки на порядки. С ними ктото работал? Или никто не работает и склоняется просто к HG индексам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 17:04 |
|
||
|
IQ и join indexes
|
|||
|---|---|---|---|
|
#18+
Join index-ы очень тяжелые, занимают много места, кроме того при изменении данных (заливка новых данных, update/delete) в таблицах на которых построен такой индекс вам надо будет явно выполнять синхронизацию такого индекса выполнив SYNCHRONIZE JOIN INDEX [join-index-name. Поэтому полностью поддерживаю совет по денормализации .. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2009, 20:27 |
|
||
|
IQ и join indexes
|
|||
|---|---|---|---|
|
#18+
Не по join-индексам, но все же наблюдение по индексам в IQ через которые объединяются таблицы. У оптимизатора IQ обнаружилось нежелание использовать составные индексы. Например были таблички t1 и t2. В обоих таблицах одинаковые поля a, b, c. Таблицы объединяются через where t1.a=t2.a and t1.b=t2.b and t1.c=t2.c. Был только один составной индекс HG (a,b,c) на каждой из таблиц. После добавления HG индексов отдельно по полям a,b,c оптимизатор стал использовать 3 отдельных индекса вместо одного составного и скорость select-ов снизилась на порядок. Пришлось отдельные индексы убить. Может есть какой то хинт для оптимизатора чтобы повысить приоритет сотавных индексов перед отдельными? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2009, 10:25 |
|
||
|
|

start [/forum/search_topic.php?author=LEAF_NODE&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
get settings: |
11ms |
get forum list: |
14ms |
get settings: |
10ms |
get forum list: |
15ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
159ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 1445ms |
| total: | 1772ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...