Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
а значения этих параметров: tmp_table_size, max_heap_table_size ? хотя и с рам-диском должно было полегчать.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2018, 15:24 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
# cat my.cnf | grep tmp_table_size # # cat my.cnf | grep max_heap_table_size # В конфиге не заданы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2018, 16:01 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Exec1 Код: sql 1. 2. 3. вы хотите сосчитать ВСЮ таблицу и тут как не ускоряйся, а время будет только расти с ростом кол-ва строк это чистый seq scan, без вариантов единственный вариант - агрегация когда не нужна агрегация, там WHERE есть, обычно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2018, 16:29 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
у меня запрос, что с сортировкой, что без - выполняется одинаково. по какой-то причине у Exec1 данные долго загоняются во временную таблицу... Exec1, попробуйте рекомендации из статей по оптимизации самого MySql сервера.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2018, 16:41 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Дормедонт Евлампиевичу меня запрос, что с сортировкой, что без - выполняется одинаково. очевидно потому, что после group by там данных сильно меньше становится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2018, 20:22 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
>> вы хотите сосчитать ВСЮ таблицу и тут как не ускоряйся, а время будет только расти с ростом кол-ва строк Да, так и есть. Не нужные данные удаляются по крону. >>единственный вариант - агрегация Тоже рассматриваю вариант. Вопрос как его оптимально сделать? Если этот запрос по крону запускать каждые 15 минут, а результат сохранять в отдельную таблицу, то это расточительство. Так как результат бывает нужен не часто. И он нужен актуальный. А подгадывать условно под каждую 15-ую минуту смешно. Проще просто подождать 6 секунд в нужный момент. Есть другая мысль, транзакция. Добавляется запись в первую таблицу, увеличиваем значение на против номера в другой таблице, удаляем запись - уменьшаем значение на единицу. Вопрос как продумать добавление нового номера во вторую таблицу, и удаление номера если его count обнулился. >> Exec1, попробуйте рекомендации из статей по оптимизации самого MySql сервера.. Так вот и пробу разобраться. Кстати, размер таблицы 300 Мб, если не ошибусь, не так уж и много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2018, 00:22 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Exec1>>единственный вариант - агрегация Тоже рассматриваю вариант. Вопрос как его оптимально сделать? Если этот запрос по крону запускать каждые 15 минут, а результат сохранять в отдельную таблицу, то это расточительство. Так как результат бывает нужен не часто. И он нужен актуальный. А подгадывать условно под каждую 15-ую минуту смешно. Проще просто подождать 6 секунд в нужный момент. запускайте хоть каждую минуту даже каждые 10 сек можно демоном запускать в таблицу скидывать только новые записи, с момента последней записи в таблице расточительства никакого, агрегированная таблица весит %5 от оригинала ну зависит конечно, как агрегировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2018, 00:55 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39640161&tid=1829871]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
26ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 227ms |
| total: | 359ms |

| 0 / 0 |
