Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
ASA 7.0.4 Есть таблица A: id - код строки, первичный ключ GOODGRPID - код товара(есть индекс) dateedit - дата изменения записи, datetime price - цена товара Записей в таблице уже более 60000 Нужно сделать быструю выборку во временную таблицу #B GOODGRPID - код товара, первичный ключ dateedit - дата последней записи price - цена в последней записи В процедуре таблица #B сейчас заполняется следующим образом: insert into #B(GOODGRPID,DATEEDIT) select GOODGRPID,max(DATEEDIT) from A group by GOODGRPID update #CUSTGOODS set PRICE = A.PRICE from A where A.GOODGRPID = #B.GOODGRPID and A.DATEEDIT = #B.DATEEDIT Структура не моя и править могу только процедуру этого заполнения. Пока записей в А было до 30000 скорость устраивала. Сейчас притормаживает и в будущем объем будет только расти. Повторю, интересует именно наилучший запрос по скорости для заполнения #B ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:22 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
а индексы можете добавлять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:23 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Да, с базой могу делать все. Не могу править в клиенте ничего, который выдает вызов процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:25 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
а на дату индекс пробовали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:28 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Рыжий Кота на дату индекс пробовали? Пробовал, но помогает слабо. Там timestamp. Я уже о триггере подумываю, чтобы при изменении записи в A где-то помечать последнюю запись для каждого товара, чтобы от группировки отказаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:36 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Прошу прошения. Допустил ошибку в тексте процедуры. Так верно insert into #B(GOODGRPID,DATEEDIT) select GOODGRPID,max(DATEEDIT) from A group by GOODGRPID update #B set PRICE = A.PRICE from A where A.GOODGRPID = #B.GOODGRPID and A.DATEEDIT = #B.DATEEDIT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:40 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Ну так как предложений новых нет ни у кого? Может кто ускорял подобное? Мне почему-то кажется что с подобной структурой данных, простое изменение текста запроса не спасет. Предложение есть такое: Добавить еще одну таблицу как #B и в триггере на таблице A ее править. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:02 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Индексы делать надо, индексы. Сделай один индекс на две колонки (GOODGRPID, DATEEDIT) и усе... -- http://www.rusug.ru] Портал рускоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:25 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Думаю, что это направление верное: "Добавить еще одну таблицу как #B и в триггере на таблице A ее править.". Триггер будет простейший, и в дальнейшем, увеличение объема таблицы А хоть до 1000000 никак не скажется на времени выборок из В. Запросы будут летать. Главное в этом деле не облажаться и хорошо отладить триггеры (удаление из А возможно?), чтоб целостность данных была. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 23:02 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
iLLer Думаю, что это направление верное: "Добавить еще одну таблицу как #B и в триггере на таблице A ее править.". Триггер будет простейший, и в дальнейшем, увеличение объема таблицы А хоть до 1000000 никак не скажется на времени выборок из В. Запросы будут летать. Главное в этом деле не облажаться и хорошо отладить триггеры (удаление из А возможно?), чтоб целостность данных была. Поддерживаю. Только еще в #B не забыть добавить поле price, чтобы вообще к таблице A обращений не было лишних. На триггерах реализуется элементарно, производительность не пострадает по той простой причине, что операция обновления каталога цен достаточно редкая, гораздо реже, чем операция получения текущей цены ;) По идее получится триггер на таблицу A для 7-ой версии: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Естественно подразумевается, что у таблицы B первичным ключом будет поле goodsgrpid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 23:41 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Все ребята, всем огромное спасибо. Я в том же направлении думал(про триггер), хотел от знающих людей мнение услышать. У меня в базе уже есть подобные вещи на таблицах оборотов товаров, правда там все сложнее, но принцип тот же. Здесь все попроще, думал оптимизацией запроса обойтись, но от судьбы не уйдешь, придется на триггере делать. Ну целостность данных, мы конечно учтем, тем более, что таблица A в репликациях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 10:49 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
antand пишет: > товаров, правда там все сложнее, но принцип тот же. Здесь все попроще, > думал оптимизацией запроса обойтись, но от судьбы не уйдешь, придется на > триггере делать. Так все-таки, составной индекс на 2 колонки GOODGRPID, DATEEDIT пробовал или нет? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 10:53 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун antand пишет: > товаров, правда там все сложнее, но принцип тот же. Здесь все попроще, > думал оптимизацией запроса обойтись, но от судьбы не уйдешь, придется на > триггере делать. Так все-таки, составной индекс на 2 колонки GOODGRPID, DATEEDIT пробовал или нет? Posted via ActualForum NNTP Server 1.3 Пробовал, тоже само по производительности. План запроса тот же. Дело наверно в колонке DateEdit, т.к. там реальный timestamp. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 11:15 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
antand пишет: >> Так все-таки, составной индекс на 2 колонки GOODGRPID, DATEEDIT пробовал >> или нет? > Пробовал, тоже само по производительности. > План запроса тот же. Дело наверно в колонке DateEdit, т.к. там реальный > timestamp. И что? Как раз его селективность будет очень хорошей в таком случае и как минимум во второй выборке он будет идеален. CREATE STATISTICS попробуй и еще раз глянь планы. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 11:50 |
|
||
|
Нужна помощь с оптимизацией запросa
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун antand пишет: >> Так все-таки, составной индекс на 2 колонки GOODGRPID, DATEEDIT пробовал >> или нет? > Пробовал, тоже само по производительности. > План запроса тот же. Дело наверно в колонке DateEdit, т.к. там реальный > timestamp. И что? Как раз его селективность будет очень хорошей в таком случае и как минимум во второй выборке он будет идеален. CREATE STATISTICS попробуй и еще раз глянь планы. Posted via ActualForum NNTP Server 1.3 Хорошо, я попробую еще раз этот путь. Все внимательно посмотрю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 11:56 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=33774038&tid=2012807]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 238ms |
| total: | 393ms |

| 0 / 0 |
