Akina, идея в том, что мне нужно смотреть сколько файлов обработано и с каким статусом. Выборка очень большая. Count считает все минуты. Данные хочу выводить в мобильном приложении и нужно придумать что туда выводить чтобы не слишком часто базу count-ом нагружать
galaxy, дал ему постоять ночь. До сих пор тупит. Я просто ума не приложу как http сервер своим коннектом к БД все может портить. Сейчас грохну его и все норм станет.
galaxy, да, именно в этот момент у меня он выполняется полторы минуты против 5 секунд. Если сейчас грохну сервис который по факту только соединение видимо держит (данные не вставляет никакие) то скорость запроса снова станет нужной - 5 секунд. Если после перезапуска COUNT сделаю то тоже все будет быстро, пока не пройдет несколько часов и ситуация не повторится.
galaxy, так самое интересное в том, что я не могу понять как зависающий сервис может тормозить запрос. Картинка следующая. В сервис прилетают INSERT и UPDATE запросы (не тяжелые) в виде текста (не prepared) и я их выполняю. Некоторые если INSERT падает с ошибкой, то я вызываю DELETE для указанных данных и повторяю вставку.
Каждые 30 минут выполняется COUNT запрос. И он отрабатывает нормально до какого-то момента пока не начинает так сильно тормозить.
Грохаю висящий микросервис -- время исполнение снова падает.
У меня просто реально даже мыслей нет как такое может происходить.
Кстати, ваш запрос выполняется чуть дольше моего. На невисячей базе 5.2 секунды против (в среднем) моего 4.9 секунды.
Может у вас есть идеи по первой части вопроса. Я реально даже не знаю в какую сторону думать. Транзакции что ли как-то заглючивают?
Спасибо большое, но вот с кешем не совсем понятно. Бывают моменты когда я запрос могу неопределенное количество раз выполнять и он выполняется медленно. Один и тот же. ничего не кешируется.
Закономерности не увидел. Один раз попробовал свой сервис грохнуть висящий на запросе. Или так совпало или почему-то запрос снова стал за 5 секунд выполняться. Но сам по себе сервис ничего не делает кроме как этот же запрос выполняет.
Сам сервис кроме получения COUNT еще INSERT делает, но он на Count зависает и не понятно может ли каким-то образом INSERT где-то подвиснуть и на это повлиять.
Developer, места с запасом. План запроса. Вот как раз нашел очередной момент когда тормозит: https://imgur.com/NwV3EAy
После этого несколько раз попробовал выполнить запрос с EXPLAIN и без -- выполняется по минуте вместо 5 секунд
Василий Банников, да так и есть, я в теле передаю запросы. Но у меня сервер изолированный и опасности инъекций нет. Запросы только от специальной софтины принимаются.
Виталий Качан, я сделал иначе. если при вставке упало, значит кидаю исключение и в нем выполняю операцию удаления дубликатов и повторную вставку. Т.к. ситуация очень редкая, но возможная, пока мне кажется не плохим вариантом.
Владимир Коротенко, Каждый генератор XML2SQL берет свой джоб. 4 потока по т.к. на процессоре 6 ядер.
Пакетную вставку не могу т.к. мне тогда нужно где-то аккумулировать все прилетевшие данные. И нужно логику по его хранению писать и потенциально 1 на 10000 записей может иметь дубликат, тогда у меня операция пакетной вставки упадет. А если пофайлово обрабатывать, то если вдруг что не так, то я четко знаю где проблема
А как их собирать на сервере? Мне прилетает набор SQL INSERT в виде текста. Есть какие-то инструменты?
У меня еще проблема в том, что в данных потенциально могут быть дубликаты (1 на 10000 запросов). Если вставка падает из-за дубликата, я выполняю удаление дубликатов и повторяю операцию вставки.