Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Альтернатива FORCE INDEX
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Сталкнулся с такой проблемой. Есть процедура которая вызываеться в цикле (с клиента) для занесения информации в таблицу. Кол-во вызывов ~10 тыс. Каждый раз процедура должна обнавить/добавить порядка 10 записей. Заметил что первые 949 вызовов проходят быстро, а дальше идут дикие тормоза (каждый вызов длиться ~1 сек). Изменение количества вызывов в транзакции на результат не повлиял. Далее было замечено что процедура начинает тормозить с определенными данными (т.е. если начинать выполнять процедуру например с 1000 записи из файла то вызов выполняеться за 1 сек. уже в 1 итерации) Выяснелось что запрос из процедуры Код: plaintext 1. 2. Код: plaintext 1. 2. В то время как select по обоим условиям выполняеться за 0,015 сек. PrefixID, RouteID - Внешние ключи Priority - поле типа integer Тригеры и доп. индексы отсутствуют. Кол-во записей ~400 тыс. Пока писал нашёл причину. При первом UPDATE выбирался не правельный индекс (по RouteID - для одного RouteID сущестует в среднем 50 тыс. записей, в то время как для PrefixID - не более 15). Поставил директиву FORCE INDEX и все отработало минуты за 2-3. Хотелось бы узнать можно ли обойтись без FORCE INDEX? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2006, 15:24 |
|
||
|
Альтернатива FORCE INDEX
|
|||
|---|---|---|---|
|
#18+
moteusЗдравствуйте. Сталкнулся с такой проблемой. Есть процедура которая вызываеться в цикле (с клиента) для занесения информации в таблицу. Кол-во вызывов ~10 тыс. Каждый раз процедура должна обнавить/добавить порядка 10 записей. Заметил что первые 949 вызовов проходят быстро, а дальше идут дикие тормоза (каждый вызов длиться ~1 сек). Изменение количества вызывов в транзакции на результат не повлиял. Далее было замечено что процедура начинает тормозить с определенными данными (т.е. если начинать выполнять процедуру например с 1000 записи из файла то вызов выполняеться за 1 сек. уже в 1 итерации) Выяснелось что запрос из процедуры Код: plaintext 1. 2. Код: plaintext 1. 2. В то время как select по обоим условиям выполняеться за 0,015 сек. PrefixID, RouteID - Внешние ключи Priority - поле типа integer Тригеры и доп. индексы отсутствуют. Кол-во записей ~400 тыс. Пока писал нашёл причину. При первом UPDATE выбирался не правельный индекс (по RouteID - для одного RouteID сущестует в среднем 50 тыс. записей, в то время как для PrefixID - не более 15). Поставил директиву FORCE INDEX и все отработало минуты за 2-3. Хотелось бы узнать можно ли обойтись без FORCE INDEX? update statistics index rebuid + update usage (не обязательно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 14:43 |
|
||
|
|

start [/forum/topic.php?fid=55&gotonew=1&tid=2012806]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
18ms |
get topic data: |
6ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 285ms |
| total: | 365ms |

| 0 / 0 |
