|
|
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Есть таблица Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. кол-во данных до нескольких десятков миллионов запросы вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. в запросах меняется дата/время , набор значений accounttype и значение accountid за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные сейчас сделаны Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 09:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
A IndexConsultant не помогает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 09:43 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Для начала нужно однозначно переписать запрос и вывести подзапрос из секции SELECT в секцию FROM. Сейчас сто процентов в плане запросов стоит Subquery, который выполняется на каждую строку основного запроса. Нужно от него однозначно избавиться. Попробуйте его соеденить с основным запросом через INNER JOIN или LATERAL, смотря что будет красивее в плане запроса и эффективнее. P.S. На будующее лучше всего показывать в сообщение помимо структуры таблицы, созданных индексов и текста запроса еще возвращаемый план запроса. Иначе без этого сложно сказать, в чем собака порылась :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 10:37 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
при таком росте данных, если позволяет бюджет, советую посмотреть Sybase IQ. Анализ CDR'ов/логов - типичная задача для IQ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 10:52 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Попробую переписать сейчас запрос, тогда план выложу, просто я нифига в нем еще не разбираюсь пока :), девятку только поставили, а раньше все по интуиции больше делалось ... IQ во первых ОЧЕНЬ дорого, во вторых он не потянет такой объем вставляемых данных, insert очень долго проходит ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:19 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Да, индексконсультант посоветовал кластерный составной индекс (accounttype, accountid, datetime) но что-то стремно как-то .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
IQ должен стоять "рядом", как база для анализа/репортинга и т.п. Перекинуть 400000 записей из АСА в IQ - дело 3-5 сек. Можно как bulk load так и proxy (insert into location). Цена - это конечно :) Вам решать :) но такие селекты решаются в пределах <X сек (с 1CPU, 512Мб RAM, 40mln row) и еще быстрее на нормальном железе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:55 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
VovakaДа, индексконсультант посоветовал кластерный составной индекс (accounttype, accountid, datetime) но что-то стремно как-то .... Это ASKRUS спец по индексам. :) Ждите вердикта. Думаю один кластерный индех не помешает, но довольно сильно увеличит базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 13:10 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
сделал составной индекс по трем полям, но не кластерный - оптимизатор им не пользуется, пользуется индексом по дате/времени с селективностью 94% .... чего-то то не понимаю совсем :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 15:39 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
1. Переписали ли Вы запрос ? 2. Если переписали, то ждем его новый текст и его план запроса. - иначе ничего сказать по поводу того, нужен ли кластерный индекс и по каким полям нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:07 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
А что такое UltraPlan ? Видимо я не туда посмотрел, потому как результаты в Plan и UltraPlan разные ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:20 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
VovakaЕсть таблица за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные. сейчас сделаны create index voip_cdr_billing_accountid_accounttype on voip.cdr_billing (accounttype, accountid); Это бесполезный (или малополезный) индекс, исходя из того, что ты сообщил. Или тут перепутан порядок полей в посте или при создании индекса. ( accountid,accounttype)???; Индексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
(ой, добавочка) ... или datetime ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUSДля начала нужно однозначно переписать запрос и вывести подзапрос из секции SELECT в секцию FROM. Сейчас сто процентов в плане запросов стоит Subquery, который выполняется на каждую строку основного запроса. Нужно от него однозначно избавиться. Попробуйте его соеденить с основным запросом через INNER JOIN или LATERAL, смотря что будет красивее в плане запроса и эффективнее. Как-то не очень бы согласился я : Из запроса не понятно, коррелированный подзапрос там или нет. Кажется, что нет. Если да, то куда его не ставь - все едино. Если запрос некоррелированный, то с какой такой стати ASA его будет для каждой строчки выполнять ? Или оно такое глупое, что ONCE AGREGATE не понимает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
MasterZiv VovakaЕсть таблица за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные. сейчас сделаны create index voip_cdr_billing_accountid_accounttype on voip.cdr_billing (accounttype, accountid); Это бесполезный (или малополезный) индекс, исходя из того, что ты сообщил. Или тут перепутан порядок полей в посте или при создании индекса. ( accountid,accounttype)???; Индексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. Перепутано здесь :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:29 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
MasterZivИндексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. блин, я думал они будут помогать делать group by e164prefix, minuteprice ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:38 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUS1. Переписали ли Вы запрос ? 2. Если переписали, то ждем его новый текст и его план запроса. - иначе ничего сказать по поводу того, нужен ли кластерный индекс и по каким полям нельзя. А что из плана нужно выложить ? там так всего много ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:58 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
авторКак-то не очень бы согласился я : Из запроса не понятно, коррелированный подзапрос там или нет. Кажется, что нет. Если да, то куда его не ставь - все едино. В скрипте подзапроса в WHERE стоит "prefix = e164prefix". Так что не едино. Во вторых ASA после переноса запроса в FROM уведет его в дерево главного плана, убрав Subquery, что уже прибавит скорости не мало. Так что переписывать нужно в обязку. авторА что из плана нужно выложить ? там так всего много ... Ставим в ISQL опцию Long Plan, нажимаем F5 и копируем результат сюда. По другому не разберешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 17:49 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Начал уже писать, что не всегда используется этот индекс, что возникают ситуации, когда появляется table scan, если в этом примере поменять accountid на определенное значение - то индексскан почему то уже не используется... в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) вот план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. так полезен ли будет кластерный индекс ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 18:05 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka MasterZivИндексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. блин, я думал они будут помогать делать group by e164prefix, minuteprice Ага, жди ... Подумай, чему они будут помогать ? Ну, не будет сервер сортировать набор данных при группировке, читая ВСЮ ТВОЮ ТАБЛИЦУ, ты же не этого наверное хочешь ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:12 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) ... так полезен ли будет кластерный индекс ? Так что ж непонятного ? Я так понимаю, это он и есть - вожделенный оптимальный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:14 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUS В скрипте подзапроса в WHERE стоит "prefix = e164prefix". Так что не едино. Во вторых ASA после переноса запроса в FROM уведет его в дерево главного плана, убрав Subquery, что уже прибавит скорости немало. Не понял. Коррелированный ? или нет ? все равно не ясно. Не факт, что e164prefix - поле из внешнего запроса - квалификатора таблицы-то нет. Перенос же в главное дерево может только замедлить, впрочем, надо сначала разобраться, коррелированный подзапрос или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:21 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) может АСА закешировала запрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka Как то я в плане запроса не вижу табличек globalprefixgroup и globalprefix. Или это уже план на другой запрос ? Просто хочется увидеть сам запрос и план на него. По плану запроса можно сказать, что он неэффективен, так как по нему оптимизатор сначала сканирует по индексу подходящие условию записи, и считывая их значения с таблицы начинает строить хэш-таблицу по полям e164prefix, minuteprice и currencyrate, аггрегируя по ним нужные поля найденных записей. Далее он запихивает результат во временную таблицу для проведения сортировки. Наличие хэша говорит, что оптимизатор не нашел подходящего индекса, а наличие времянки говорит, что самих групп возвращается много и не хватает кэша памяти ASA для их размещения. Так что еще раз хочу сказать, что нужно пока забыть про индексы и более удачно переписать запрос, добившись того, чтобы в нем не было использования хэш алгоритма группировки (он хорош, только при условии малого кол-ва групп). авторНе понял. Коррелированный ? или нет ? все равно не ясно. Не факт, что e164prefix - поле из внешнего запроса - квалификатора таблицы-то нет. Перенос же в главное дерево может только замедлить, впрочем, надо сначала разобраться, коррелированный подзапрос или нет. Вся хитрость в том, что ASA != ASE почти во всем: 1. Квалификатор таблицы для указания поля связи в этом подзапросе не нужен, если таблицы подзапроса не имеют такого же поля. Хотя правильней его писать, чтобы вот потом не возникало таких споров. 2. Запрос явно является коррелированным, так как связывается по полю e164prefix с основным запросом, а так как он аггрегированный, то ASA потребовала бы включить его в группировку, что и сделано в запросе. 3. Перенос в главное дерево, т.е. избавление от Subquery всегда увеличивает скорость работы подзапроса в ASA, только при условии, если правильно переносить :) Например в данном случае переносить запрос нужно в основной запрос не через соединение INNER JOIN, а как LATERAL (прямое внутреннее соединение, которое позволяет внутри подзапроса ссылаться на поля главного запроса, но при этом алгоритм его выполнения эффективнее, чем работа с Subquery). авторТак что ж непонятного ? Я так понимаю, это он и есть - вожделенный оптимальный план. Как я уже и говорил выше, ничего хорошего в этом плане нет, учитывая размеры таблицы. Хэш-таблицы ASA начинает использовать не от хорошей жизни, а от вынужденной необходимости хоть как то обработать огромный массив записей. авторможет АСА закешировала запрос? Кэш не влияет на построение плана запроса. В данном случае правильный ответ будет из фразы: авторв общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) а если вспомнить, что в ASA обучающийся эвристический анализатор, который после выполнения каждого запроса сравнивает полученные результаты с предполагаемыми, корректирует статистику по полям таблицы и индексов и начинает вести рэйтинг планов запросов, то этим скорее всего и обьясняется пропажа TableScan-а. Ну еще как вариант - это изменение условий запроса, которые привели к тому, что в выборках стала участвовать не сильно много записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:43 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
в общем вот запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. индекс в таблице только один (accountid, accounttype, datetime) вот план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. пробовал сделать подзапрос через join - выигрыша нет Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. а вот как избавиться от хэшей ? результат выборки, в зависимости от периода может достигать сотен тысяч записей, в данном случае за сутки до десятков тысяч, после группировки остается максимум сотни две ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 09:08 |
|
||
|
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/topic.php?all=1&fid=55&tid=2014148]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
142ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 487ms |

| 0 / 0 |

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