Я в свое время писал собственный mvvm фреймворк,там навигация была организована через команды

Правда,я там и всю отрисовку в шаблонах делал

Как запрос оптимизировать можно? select user_models.*, count(user_id) as count_messages from chat_logs inner join user_models on user_models.id = user_id where chat_id = ? group by user_id

В таблице 100к записей, запросом выбирается 100 записей, занимает 2 секунды

проверить наличие индексов

БД mysql если что

Точнее mariadb

проверить наличие индексов

На айдищниках и так они стоят по которым фильтрация и join

Да, на айдишниках индексы стоят

Без inner join запрос выполняется 1 секунду

Ну вот и на джоин приходится секунда вторая

В любом случае, не слишком ли медленно?

Две секунды на простой запрос к таблице где не так много данных, жирно

Две секунды на простой запрос к таблице где не так много данных, жирно

У меня из за left join время скакнуло с 63 мс до 6300 мс

В 100 раз Карл!

Добавил user_id и chat_id в отдельный индекс, на секунду быстрее стало

Теперь с inner join быстрее выборка происходит?

Покрывающие индексы это очень хорошо

Ты смотри план и что там жрет время

И не быстрее ли будет поменять таблицы местами?

Щас посмотрю

А план как посмотреть?

Хуй знает

оптимизатор сам знает в каком порядке таблицы джойнить

нормальный оптимизатор

А план как посмотреть?

В какая бд?

mariadb

оптимизатор сам знает в каком порядке таблицы джойнить

Не стоит на него полагаться

А если вместо count(...) Написать count(1)

А план как посмотреть?

https://www.sitepoint.com/using-explain-to-write-better-mysql-queries/

вообще в воркбенче и наверно в других клиентах будет визуально

Просто интересно будет ли такой запрос быстрее, попробуй:

select user_models.*, count(1) as count_messages from chat_logs inner join user_models on user_models.id = user_id and chat_id = ? group by user_id

https://www.sitepoint.com/using-explain-to-write-better-mysql-queries/

С индексами всё ок

select user_models.*, count(1) as count_messages from chat_logs inner join user_models on user_models.id = user_id and chat_id = ? group by user_id

Этот запрос: /* Длительность 1 запрос: 1,156 sec. */ Мой запрос: /* Длительность 1 запрос: 1,078 sec. */

Не получилось :)

я может чё не понимаю, но как можно выбрать в селект столбцы, которых нет в аггрегирующей функции?

Он из той таблицы не берёт ничего кроме каунта

мускуль умеет

user_models.*, - это тогда что?

ааа и какой будет результат?

user_models.*, - это тогда что?

Все поля таблицы user_models

Вообще я бы по рукам бил за отсутствие алиасов везде

я может чё не понимаю, но как можно выбрать в селект столбцы, которых нет в аггрегирующей функции?

Я кстати тоже не совсем понял, но я с mysql не работал. Тоже интересно, как он сгрупирует?

А нафиг здесь алиасы?

А если он их(столбцы без агр. функции не группирует) то зачем там group ?

Чтобы не гадать какой столбец откуда и в будущем не ловить баг ambiguous column

"MySQL допускает выполнение запросов, не удовлетворяющих данному правилу. При этом для полей без групповых функций и не указанных в части GROUP BY выбирается произвольная строка из группы"

Чтобы не гадать какой столбец откуда и в будущем не ловить баг ambiguous column

Обжект маппер разрулит всё

БД mysql если что

Сменить бд

Вот как раз оно для оптимизации

Например на рассово верную арийскую сверх базу - мсскл

На оракл!

Мы же не пхп кодеры в конце концов

Ну не знаю, на слабом железе хостить mssql такое

Ну не знаю, на слабом железе хостить mssql такое

20 Гб фри на амазоне

Бесплатно

Абсолютно

Безвозмездно

На мсскл

К тому же, мне не нужно гигабайты данных перебирать сложными запросами

20 Гб фри на амазоне

Шило на мыло

Почему?

Там достаточно мощный сервер

ERROR: S client not available

Разворачиваешь базу в 2 клика

В франкфурте

Угу, а сервер в России

И гоняй данные туда-сюда

Угу, а сервер в России

А сервер на ДО

Тоже в Германии

И пинг 0

Короче, такое себе

Мне лучше базу хостить у себя

Ну разве что тебе нужно деплоить локально

Мне лучше базу хостить у себя

Ты комп не выруьаешь?

Вырубаю

У меня raspberry есть, на ней всякие свои тулзы хостятся

А тогда ок

Если на расбери

Тогда 100% оправдано

;)

Если полноценно чето разворачивать то я б брал такую связку

Оч быстро выходит

И многим клиентам хватает

Обычно лоулоад и они базу особо не дрючат

А 20гб я хз сколько написать можно

Ну серьёзно, неужели mysql не может быстро выборку сделать из 100к записей?

А почему не постгрес? На слабом железе тоже на ура

Вот я и думаю, почему не постгрес)

Но постгрес вроде тоже не идеален

Мне лучше базу хостить у себя

Дурак глупый

Щас бы не асилилить авс или ажуру

Где под сракой мощные сервера

Угу

И хостить там телеграм бота