|
|
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Если LATERAL пользоваться нельзя, то лучше тогда оставить как есть в subquery. Насчет оптимизации главного запроса: можно попробовать группы скинуть во времянку и поэксперементировать с соединениями. Тогда вполне возможно можно будет сделать составной индекс, первыми полями которого идут поля группировки, а потом поля фильтра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 09:47 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUS Вся хитрость в том, что ASA != ASE почти во всем: В планах запросов он точно !=. Я так понял тот план, что это просто выполнение группировки. ASCRUS 1. Квалификатор таблицы для указания поля связи в этом подзапросе не нужен, если таблицы подзапроса не имеют такого же поля. Хотя правильней его писать, чтобы вот потом не возникало таких споров. В ASE тоже не нужен. Да и вообще, это ANSI -стандарт требует. Так что не так уж и !=. ASCRUS 2. Запрос явно является коррелированным, так как связывается по полю e164prefix с основным запросом, а так как он аггрегированный, то ASA потребовала бы включить его в группировку, что и сделано в запросе. Там это само поле e164prefix тоже есть в списке вывода. Есть или нет e164prefix в двух таблицах подзапроса - мы не знаем. Да и вообще, что гадать ? Пусть товарищь пришлет скрипты на таблицы и запрос, и план его. Тогда можно о чем-то говорить. ASCRUS 3. Перенос в главное дерево, т.е. избавление от Subquery всегда увеличивает скорость работы подзапроса в ASA, только при условии, если правильно переносить :) Например в данном случае переносить запрос нужно в основной запрос не через соединение INNER JOIN, а как LATERAL (прямое внутреннее соединение, которое позволяет внутри подзапроса ссылаться на поля главного запроса, но при этом алгоритм его выполнения эффективнее, чем работа с Subquery). Впервые слышу про такого зверя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 11:51 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
вот скрипты, но этот подзапрос для выдергивания имени особенно не требует времени, т.к. результат группировки содержит небольшое кол-во строк Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. а LATERAL появился только в ASA 9 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 12:08 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Ты думаешь, сервер сначала выполняет группировку, а потом подзапрос ? Далеко не факт, что так будет. Обычно происходит как раз наоборот. Что в твоем случае будет достаточно плохо. Кстати, если это поле, которое подзапрос выводит, одно на запрос, то можно его в переменную выбрать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 12:18 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
используя LATERAL получаетсядаже чуть хуже Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. и всем огромное спасибо p.s. а ASCRUS еще и отдельное за статью об индексах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 12:18 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Index: Код: plaintext 1. Query: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. HTH, Linas ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 12:32 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Linas Так как: Код: plaintext Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 13:38 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Кстати если выборка аналитического характера и может строиться с некоторым опозданием во времени, то стоит подумать о введении табличек, хранящих аггрегаты и автоматом рассчитывающихся в определенные промежутки времени (фактически аналог материализованных представлений). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 14:33 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Da, nepodumal pro interval. Togda problema. Mozno poprobovat tak: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 15:36 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Или подождать ASA Jasper - там будут Materialized views. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 15:37 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Рассматривая original QUERY я бы сказал что ету проблему надо решать несколько иначе. Учитывая то что ты делаеш выборку всего за 2 дня то максимальное колличество выбранных рекордов у тебя должно быть дге-то в пределах 800000 - ето не так уж много. Поэтому основное решение должно быть в разбивке твоего одного QUERY на несколько этапов: 1. Создание временной таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Код: plaintext 1. 2. Основная выборка во времменую таблицу: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Я бы заменил CLAUSE "datetime between '2004-08-25' and '2004-08-26'" на более простое выражение - SYBASE это выполняет быстрее. Этот SELECT вернёт больше рекордов зато индексы voip_cdr_billing_accountid_accounttype и voip_cdr_billing_datetime будут работать и ты не будеш гонять JOIN (или CORRELETED SUBQUERY) на остальные 2 таблицы (tel.globalprefixgroup i tel.globalprefix) на все миллионы рекордов. 3. Чистка Код: plaintext 1. 2. 3. 4. 5. 6. 4. Update Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. В данном случае даже не надо делать GROUP BY 5. Final SELECT Код: plaintext 1. 2. 3. Код: plaintext 1. Вся ета структура может быть более громоздкая зато оптимизация будет лучше и все индексы будут работать. _________________________________ Евгений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2004, 05:52 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Только сейчас обратил внимание что у тебя ASA а не ASЕ. В этом случае временную таблицу надо создавать в схеме voip и не обязательно использовать #. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2004, 06:07 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Мои 2 цента (копейки)... Судя по Вашему запросу, независимо от того, насколько велика таблица, диапазон дата от ... до, по всей видимости - 1 месяц в 99% случаев. Это и есть то условие, которое позволит сделать Вашу таблицу "маленькой", ибо время (т.е. поле "дата транзакции") - как раз и есть та "ось" по которой ваша таблица растет. Поэтому я бы все индексы, которые могут прийти в голову, начинал бы с этого поля. Из того что могу предложить сам (пальцем в небо) - индекс по дате, потом по тому, что у Вас стоит в GROUP BY. Тип счета на мой взгляд не надо, он должен сам ручками перебрать. Честно, не знаю как он group by обрабатывает, так что может ничего и не выйдет. На ваш план я еще не поглядел толком - дома гляну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2004, 21:00 |
|
||
|
|

start [/forum/search_topic.php?author=Balamutikweb&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
157ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 491ms |
| total: | 765ms |

| 0 / 0 |

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