LINUX.ORG.RU

Как ускорить тяжелые запросы в MySQL?

 


1

1

Можно ли ускорить тяжелые запросы в MySQL?

Сделал лог долгих запросов, там полно такого:

# Time: 200201 17:47:26
# User@Host: root[root] @ localhost [127.0.0.1]
# Thread_id: 71841 Schema: tgadmin_test QC_hit: No
# Query_time: 72.940765 Lock_time: 0.000165 Rows_sent: 51075 Rows_examined: 51075
# Rows_affected: 0 Bytes_sent: 28192695
SET timestamp=1580575646;
SELECT * FROM tgmanager_delayedtasks WHERE completed = 0 AND dt < '2020-02-01 17:46:13.893177';


И все на одну и ту же таблицу. Запрос возвращает десятки тысяч строк, и , к сожалению, все поля нужны, исключить могу максимум одно. Проставил на эту таблицу индексы на dt и completed - не помогло.
Что-то можно сделать, чтобы такой запрос проходил быстрее?

P.S. Почему-то разметка при редактировании только User line break. Поле неактивное. Не выходит добавить ни лоркод ни маркдаун

★★★★★

Последнее исправление: Qwentor (всего исправлений: 5)

Ответ на: комментарий от Qwentor

Таак, не везде закрыл.
Сейчас дозакрыл везде, буду смотреть. Возможно оно. Админка теперь грузится со скоростью ракеты, а было медленно и печально

Qwentor ★★★★★
() автор топика
Ответ на: комментарий от Qwentor

Нет, все равно есть эта ошибка (2006, 'MySQL server has gone away')

Qwentor ★★★★★
() автор топика
Ответ на: комментарий от KivApple

Я бы сделал на completed,dt,

+1.

но ниже почему то советуют в обратном порядке.

Не секут от слова совсем. Даже объяснять влом почему для условия (complete=0 and dt > …) это то же самое что индекс по dt (только места больше займёт).

Впрочем, тут столько всего уже нафлудили, что я пожалуй внесу свою лепту: мускуль – говно, для начала надо перейти на постгрес.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

мускуль – говно, для начала надо перейти на постгрес

Это будет тяжко. Все уже на мускуле построено, кода дофига.
Постгрес сильно лучше?

Есть ли еще советы по мускулю? А то пошумели и разбежались(

Qwentor ★★★★★
() автор топика
Ответ на: комментарий от Qwentor

Есть ли еще советы по мускулю? А то пошумели и разбежались(

Советы, как всегда - думать мозгом.

Неплохо бы определить обстоятельства, при которых это происходит, чем вызвано.

Ты хоть пробовал наблюдать как этот дело на клиенте происходит? Чем ты подключаешься?

Я правда так и не понял, а клиент-то что говорит и как реагирует, и главное в какой момент?

Смотреть внимательно логи, может какое более вербозное логгирование есть?

Кстати можно попробовать на марию перейти или перкону или фирменный mysql или что там сейчас есть. Версию обновить тоже неплохо бы. Кофиг сбросить до дефолта. Это метод тыка, конечно, но всё же.


Постгрес сильно лучше?

тебя в данном случае или клиент криво работает, или что-то с сетью или хостер тебе говно какое-то дал вместо сервера. Ну как бы все те же самые проблемы были бы у тебя и на постгресе. Как мне кажется, это очевидно. Ну либо еще какая-то кривизна рук или неожиданность, но там то же самое.

В контексте твоей задачи и твоего понимания, там та же таблица, те же индексы тот же запрос. Если ты свою проблему не можешь тут решить в постгресе ты точно так же не сможешь ее решить.

Если тебе «иксперд» по mysql советует переходить на постгрес, то знай - никакой он не эксперт ни в том ни в другом, а обыкновенное быдло ориентирующееся на толпу. Он конечно тебе будет рассказывать как хорош постгрес, правда он сам конечно дуб-дубом в нем, реальных возможностей этих систем он не знает, да mysql у него «плох» на основании его «опыта» написания трех запросов.

anonymous
()
Ответ на: комментарий от anonymous

Неплохо бы определить обстоятельства, при которых это происходит, чем вызвано Очень сильно многопоточное приложение, более 200 потоков точно, а так они там динамически добавляются. Когда это приложение выключено, админка, к примеру, ошибок не выдает

Ты хоть пробовал наблюдать как этот дело на клиенте происходит? Чем ты подключаешься?

Админка на джанге периодически выдает (2006, ‘MySQL server has gone away’)

В лог идут сообщения вида:

2020-02-01 22:40:06 193 [Warning] Aborted connection 193 to db: 'tgadmin_test' user: 'root' host: 'localhost' (Got an error reading communication packets)

При подключении хоть каким графическим клиентом к базе ни разу не словил ни одну из этих ошибок

попробовать на марию перейти

и так мария - MariaDB 10.4.7

Qwentor ★★★★★
() автор топика
Последнее исправление: Qwentor (всего исправлений: 1)
Ответ на: комментарий от anonymous

Неплохо бы определить обстоятельства, при которых это происходит, чем вызвано

Хм.. Кажется я не на того думал. Вот сейчас завершило работать ДРУГОЕ приложение (отключается ночью) и все ошибки магическим образом перестали сыпаться в лог. А я думал на основное) Аж переписал его основательно. Но пофиг, не зря - до переписывания потребляло 20-25% оперативной памяти сервера, сейчас что-то около 3%.

С джангой вроде тоже разобрался, там CONN_MAX_AGE в настройках джанги должен быть меньше wait_timeout в my.cnf , а у меня был больше

Qwentor ★★★★★
() автор топика
Последнее исправление: Qwentor (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.