|
|
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Имеется стандартная база Syslog Код: sql 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. В SysLogTag много всего но в основном 'web-proxy,account' В Message приблизительно ' 192.168.127.23 GET http://i47.fastpic.ru/big/2013/0504/4b/c7d17bcb8543bd367cdd17416ce8424b.gif action=allow cache=MISS' Выборка из 400000+ строк (61 всего, Запрос занял 0.0538 сек.) Терпимо Код: sql 1. 2. 3. 4. 5. Но когда пытаюсь сортировать все плохо (61 всего, Запрос занял 3.4549 сек.) Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 00:23 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуков, Показывайте точные запросы и их планы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 00:55 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoft, это и есть точный запрос Без сортировки Код: sql 1. 2. 3. 4. С сортировкой Код: sql 1. 2. 3. 4. 5. первый 0.0538 сек. второй 3.4549 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:13 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
И планы запросов, пожалуйста. Попутно попробуйте такие варианты: Код: sql 1. 2. 3. 4. 5. Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:18 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуковпервый 0.0538 секА это точно результат не из кэша? добавьте слово SQL_NO_CACHE сразу после слова SELECT, чтобы кэш запросов не влиял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:20 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
EXTPLAN без сортировки select_type:SIMPLE Table:se Type:ALL possible_keys:NULL key:NULL key_len:NULL ref:NULL rows:400635 Extra:Using where; Using temporary с сортировкой Extra:Using where; Using temporary; Using filesort ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:22 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуков Код: sql 1. Для какой доли записей выполняется это условие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:24 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 61 всего, Запрос занял 0.0560 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:25 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoftНиколай Жуков Код: sql 1. Для какой доли записей выполняется это условие? Сейчас 70% планируется 90-98% miksoftПопутно попробуйте такие варианты: (61 всего, Запрос занял 3.3338 сек.) для GROUP 3.56 ORDER ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:31 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoftНиколай Жуков Код: sql 1. Для какой доли записей выполняется это условие? Исправляюсь 400635 из 419356 как раз уже 96-98% ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:36 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Заметил что Код: sql 1. 2. 3. 4. 5. работает быстрее но не значительно 3.1-3.2 сек. А без сортировки вообще летает (61 всего, Запрос занял 0.0484 сек.) Также сортировка без повторной распаковки IP в два раза быстрее (61 всего, Запрос занял 1.7083 сек.) Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 02:15 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуковmiksoftпропущено... Для какой доли записей выполняется это условие? Исправляюсь 400635 из 419356 как раз уже 96-98%т.е. 400 тысяч записей, но из них условию INET_ATON(...)>0 удовлетворяют только 61? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2015, 12:41 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
tanglirт.е. 400 тысяч записей, но из них условию INET_ATON(...)>0 удовлетворяют только 61?Это же после distinct-а. Т.е. они сильно повторяются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2015, 13:05 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksofttanglirт.е. 400 тысяч записей, но из них условию INET_ATON(...)>0 удовлетворяют только 61?Это же после distinct-а. Т.е. они сильно повторяются.Упустил этот момент. Если целых три секунды, то наверное да, повторяются. Ну тут кроме выделения этого INET_ATON(...) в отдельное индексированное поле вариантов, наверное, и нет. Хотя... ТС так и не ответил, сколько работает этот запрос miksoft Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2015, 13:52 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
tanglirХотя... ТС так и не ответил, сколько работает этот запросНасколько я понял, ответил тут - 18538268 в последней строке поста. Меня вот смущает ситуация, когда 61 запись "добывается" довольно быстро (хотя перелопатить нужно много), а их же отсортировать - долго (хотя объем копеечный). Не первый раз вижу такой "заскок" у MySQL, но как лечить - не знаю. До сих пор если и удавалось, только только вариациями запроса. Или вообще записать в промежуточную таблицу и читать с сортировкой из нее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2015, 13:56 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Извиняюсь за пробел во времени, в командировке был. Попытаюсь ответить на все что пропустил. База уже 968k записей. Строка с которой производятся манипуляции ( 192.168.127.23 GET http://i47.fastpic.ru/big/2013/0504/4b/c7d17bcb8543bd367cdd17416ce8424b.gif action=allow cache=MISS) Запрос без сортировки. Всего отвечающий требованию строк после DISTINCT (80 всего, Запрос занял 0.0495 сек.) Код: sql 1. 2. 3. 4. 5. Я так понимаю что ORDER с начало сортирует 970k записей а потом делает DISTINCT Иначе объяснить что аналогичный запрос с сортировкой (80 всего, Запрос занял 6.8354 сек.) Код: sql 1. 2. 3. 4. 5. 6. (80 всего, Запрос занял 8.4260 сек.) miksoft Код: sql 1. 2. 3. 4. 5. 6. 7. miksoftНасколько я понял, ответил тут - 18538268 в последней строке поста. Прирост в скорости между DISTINCT+ORDER и GROUP я бы списал на временную загрузку железа И если можно то по подробнее вот об этом miksoftИли вообще записать в промежуточную таблицу и читать с сортировкой из нее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 14:57 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай ЖуковИ если можно то по подробнее вот об этом miksoftИли вообще записать в промежуточную таблицу и читать с сортировкой из нее.Да прям буквально и сделать - создать табличку, заполнить ее запросом без сортировки из начала топика (который выполняется 0.0538 сек.), а потом сделать выборку из этой таблички с сортировкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 15:50 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoftНиколай ЖуковИ если можно то по подробнее вот об этом пропущено... Да прям буквально и сделать - создать табличку, заполнить ее запросом без сортировки из начала топика (который выполняется 0.0538 сек.), а потом сделать выборку из этой таблички с сортировкой. Создал таблицу Код: sql 1. 2. 3. Добавлено 80 строк. (Запрос занял 8.9161 сек.) Код: sql 1. 2. 3. 4. 5. Результат для запроса без INSERT(80 всего, Запрос занял 0.0511 сек.) Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 17:25 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай ЖуковДобавлено 80 строк. (Запрос занял 8.9161 сек.)А если очистить табличку и повторить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 17:38 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoft, Это сразу после очистки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 17:52 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуковmiksoft, Это сразу после очисткиСуть не в очистке, а в повторе запроса. Не понимаю, куда там могут 8 секунд потратиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 17:59 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуков, а если табличку сделать engine=memory? ну так, в порядке бреда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2015, 20:11 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
tanglirНиколай Жуков, а если табличку сделать engine=memory? ну так, в порядке бреда. Готов проверить любой бред Знать бы как ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2015, 09:32 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай ЖуковЗнать бы как Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2015, 10:01 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
tanglirНиколай ЖуковЗнать бы как Код: sql 1. 2. 3. Честно в полном недоумении (Запрос занял 0.0049 сек.) Код: sql 1. 2. 3. Добавлено 80 строк. (Запрос занял 9.0948 сек.) Код: sql 1. 2. 3. 4. 5. Сам запрос (80 всего, Запрос занял 0.0561 сек.) Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2015, 11:32 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Да уж, это круче чем мой баг с рандомом А такой запрос Код: sql 1. 2. 3. 4. 5. 6. тоже выдаст 9 и 0.05 с инсертом и без соответственно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2015, 13:47 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Можно добавить индекс на поле `Message` и сортировать по нему. Если оно начинается с IP - то сортировка будет работать как надо и очень быстро. Длину индекса кстати можно указать - varchar(17), так как для сортировки нам важный первые 17 символов (_XXX.XXX.XXX.XXX) Рекомендую никогда не делать сортировку по не индексированному полю. В вашем случае конечно интерпретатор работает интересно. Может быть он считает сортировку в данном случае более простой операцией, чем условия WHERE и выполняет ее раньше. Для всех строк - это долго. При использовании LIMIT это было бы оправдано. Но это лишь мое предположение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2016, 05:24 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
Николай Жуков, зачем вам скорость? кто пользователь? у вас такие запросы идут по 5 штук в секунду? Если нужно часто, имеет смысл копать в сторону логический улучшений: 1. Вместо постояной дро..и распоковки и пасинга можно распарсить message на вставке. добарить деривативные (расчетные) поля IP и ValidIpFlag=(0|1) и соответсвыюший индекс(ы) Код: sql 1. 2. 3. 4. 5. 6. 7. 2. создать агрегированую таблицу уникальных ИП на каждый день или там каждый час. Дополнять таблицу по истечении очередного промежутка. Если надо иметь результат до последней секунды, то выбирать значения из пре-агрегатной таблицы до поледнего часа а потом просчитывать динамически только последние минуты после часа. Это вариант грамчик сложноватенький по организации зато получите результат порядка нескольких милисекунд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2016, 06:19 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
javajdbcзато получите результат порядка нескольких милисекундУ него и так было 50-60 мс. Хотя я не понимаю, почему так быстро. А при вставке в таблицу или еще каком-либо использовании результата запроса размером в 80 несчастных записей вдруг время подскакивает до 9 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2016, 13:41 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
miksoftjavajdbcзато получите результат порядка нескольких милисекундУ него и так было 50-60 мс. Хотя я не понимаю, почему так быстро. А при вставке в таблицу или еще каком-либо использовании результата запроса размером в 80 несчастных записей вдруг время подскакивает до 9 секунд. да, тут какая-то техническая проблема. Но кроме любопытсва почему имено такой запрос рабодает через пень-колоду -- мне не нравится сама идея часто перелопачивать (в основном статические) милион записей чтобы выташить 80 значений. Интереснее решать бизнес / логические задачи, заранее приготовить данные для быстрого потребления , пре-агрегировать, итд... Однозначно плохо иметь такую недетерминированую ситуацию, но как бы база сама намекает что запрос "корявый"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2016, 01:49 |
|
||
|
Сортировка после distinct SUBSTRING_INDEX(...)
|
|||
|---|---|---|---|
|
#18+
javajdbcзаранее приготовить данные для быстрого потребления , пре-агрегировать, итд... Однозначно плохо иметь такую недетерминированую ситуацию, но как бы база сама намекает что запрос "корявый"... Я и забыл про этот пост уже Подготовить данные нет возможности Речь идет о стандартном syslogd mysql На Ubuntu Все что могу это добавлять индексы но колонка messages - text А лог отправляют аппаратные маршрутизаторы Мне если честно и сортировка то не нужно Но просматривает начальство а им подавай цифры по порядку чтоб искать проще Если есть возможность связать две таблицы вместе (средствами mysql) И во вторую таблицу автоматически распарсивать messages из первой по колонкам с индексами по мере добавления. то это наверно единственный вариант, после переписывания syslog под себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 01:36 |
|
||
|
|

start [/forum/topic.php?all=1&fid=47&tid=1832082]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 494ms |

| 0 / 0 |
