|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
SQLite последней версии (в смысле могу использовать любую) Код: plaintext 1. 2.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
1. Сейчас так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Вобщем этих селектов в реале много и конструкции "FROM i WHERE g.rowid = i.g" у них одинаковые хочется как-то написать их в одном месте. Пробовал: 2. Казалось-бы самая логичная запись Код: plaintext 1. 2. 3. 4. 5. 6.
но работает очень-очень медленно. Как будто таблица подзапроса генерируется вся, а потом сопоставляется. 3. Минимальный размер таблицы подзапроса Код: plaintext 1. 2. 3. 4. 5. 6. 7.
сильно быстрее 2-го, но все-равно медленнее 1-го. Да и опять дубли "WHERE expr1(g.a, g.b)" на деле expr1, expr2 довольно простые, так что можно делать индексы и в первом варианте индексы работают. В остальных — не очень. Надо прописывать руками через INDEXED BY. ANALYZE не помогает. Скорее даже наоборот. Как это правильно делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2009, 10:08 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Лучше сначала ограничить выборку (можно подзапрос использовать), а потом делать группировки. Посмотреть, что же реально получается, так: explain query plan ... explain ... Если запрос выполняется дольше десятков миллисекунд (откуда мне знать, что для вас значит "медленно"), бывает полезно создавать временные виды и таблицы. Можно ускорить все запросы за счет увеличения размера страницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2009, 15:08 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Как составить запрос, чтоб оптимизатор его максимально хорошо оптимизировал. Сейчас он только хуже делает. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2009, 16:05 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Вы читаете, что вам отвечают? Вместо того, чтобы методом тыка ковыряться, исследуйте указанным образом поведение ваших запросов, чтобы узнать, где какие индексы используются и какие нужно создать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2009, 20:18 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Читаю. Делаю. Выяснил что дело вовсе не в структуре запроса, а в кривом оптимизаторе. Например однострочный запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
На деле падение скорости после Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2009, 07:18 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Все дело в кривых руках. У вас отсутствует индекс по полю c.p3, о чем и говорит анализатор. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2009, 22:15 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
MBGВсе дело в кривых руках. У вас отсутствует индекс по полю c.p3, о чем и говорит анализатор. Что уж вы меня так... При ?1 = 0 этот индекс работать не будет - переберутся все строки с. Всего у c.p3 значений 2 штуки разных может быть. Таблица сама маленькая (77 элементов), перебрать ее не долго. На изменение значения ?1, как мне показалось, оптимизатор не среагировал, как и на удаление всего условия . Да и не должен, потому что они пишут не используют индекс на "OR". Индекс не даст увеличение скорости в 200 раз. Как я вижу ситуацию: Код: plaintext 1. 2.
По индексу a.user пробегает все подходящие а Код: plaintext 1. 2.
После анализа Код: plaintext
Код: plaintext
Код: plaintext
Код: plaintext
Почему он решает что так быстрее? Ведь у него есть спектры. Причем они сами не отрицают, что анализатор кривой. Я думаю, надо оптимизировать запросы руками и всех делов. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2009, 20:51 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
Раз уж вы заговорили о "кривости", я решил уточнить ;-) Ниже приведена аргументация. Что касается анализатора, то с ним в данном случае все ок. Как пример приведу таблицу и запрос из биллинговой системы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Условия вида (args='01 01 01' or '01 01 01'='') совершенно обычные и используются повсеместно. Никаких проблем у оптимизатора с ними нет, как вы можете видеть выше. В системе, выбранной в качестве примера, несколько тысяч портов в означенной таблице, принадлежащих десятку АТС. За месяц накапливается пара миллионов записей о звонках, которые биллингуются целиком менее 20-ти минут - при том, что каждый номер проверяется по таблице внутренних и определяется направление звонка по таблице из десятков тысяч направлений (при реалтайм биллинговании система и вовсе "прохлаждается"); итого за 500 секунд обрабатывается около 10 миллионов запросов различного вида (поиск порта, номера внутреннего, направления звонка, услуги пользователя по номеру и т.п.), не считая выполнения скриптового кода (на языке tcl). P.S. Посмотрите опции компиляции SQLite, сравните с версией из моего debian-репозитория, - от этих опций многое зависит. Мною написан набор патчей, но вот как раз планировщик не трогаю, ибо нет в том необходимости. Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2009, 23:25 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
MBGКак пример приведу таблицу и запрос из биллинговой системыsqlite используется только для первичного накопления и обработки и потом данные из нее куда-то сливаются или все так в ней и лежит? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2009, 08:39 |
|
Упростить сложный агрегат
|
|||
---|---|---|---|
#18+
СержMBGКак пример приведу таблицу и запрос из биллинговой системыsqlite используется только для первичного накопления и обработки и потом данные из нее куда-то сливаются или все так в ней и лежит? SQLite используется и как основная БД и для первичной обработки. Демоны сбора статистики с АТС хранят данные в in-memory БД, периодически сливая в базу на диск, притом сразу же ротируя данные по месяцам - таким образом, старые базы легко можно сбросить в архив, а размер каждой базы порядка гигабайта независимо от того, сколько лет работает система. Для управления разделенной базой написана свои функции. Схема баз разрешает их слияние (дубликаты игнорируются) - полезно, когда сбор статистики ведется на нескольких хостах для надежности. Основная база содержит данные о пользователях, атс, тарифах и проч. - она относительно небольшая. Таким образом, избавляемся от блокировок в многопользовательском доступе - основная база изменяется через веб-интерфейс независимо от биллингования баз с трафиком за месяц. Сами тарифы реализованы в виде скриптов, имеющих доступ к БД - позволяют задавать совершенно произвольные правила обработки трафика (используются через веб-интерфейс и напрямую при биллинговании), функции интроспекции позволяют удобно управлять тарифами через веб-интерфейс, см. Телефонный биллинг: тариф "Направление посекундно" ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2009, 10:30 |
|
|
start [/forum/topic.php?fid=54&msg=36324391&tid=2009412]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
100ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 542ms |
total: | 727ms |
0 / 0 |