При работе с СУБД MySQL столкнулся с проблемой которая повергла меня в ступор ибо я долго не мог понять из-за чего это происходит. Симптомы банальны: СУБД тупо не отвечает на посылаемые ей запросы. При этом никаких ошибок так же не отдаёт и исправно принимает запросы. Т.е. запросы уходят к СУБД а в ответ ничего, совсем ничего. Вот уж не знаешь что и думать в такой ситуации. Разумеется перезагрузка сервера баз данных помогает, но ведь это не выход надо искать причину проблем.
Всё оказалось банально просто. Всё дело в том, что СУБД ведёт себя так когда достигнут лимит запросов от пользователя. Это весьма редкая штука т.к. большинство администраторов баз данных не парятся и не ставят пользователям базы лимиты на такие, казалось бы, сущие мелочи и пустяки. Однако особо дотошные делают это вставляя палки в колёса всем другим. В общем создали юзера БД и выставили ему лимит на запросы. Как только этот лимит достигнут СУБД начинает партизански молчать не отвечая совсем ничего и самое поганое то, что в логах тоже всё чисто и нет ни слова об таком поведении.
Люди рвут на себе волосы и лезут на стены, а тут всё просто. Большие запросы тупо долго висят в стеке выполнения и задерживаются в общей очереди, когда очередь достигает максимума (лимита запросов), то всё СУБД перестаёт отвечать на все запросы пользователя у которого закончился лимит. Разумеется в СУБД MySQL для таких случаев для администратора сервера всегда припасено свободное подключение, но обычные пользователи БД страдают. Причём висеть запросы могут очень долго под различными статусами. В общем ближе к делу. В СУБД MySQL, например, посмотреть очередь запросов конкретного юзера можно командой SHOW PROCESSLIST
. Выведется таблица со списком текущих открытых работающих процессов. Там будет id процесса, его статус и собственно весь текст запроса. В таких сутуациях проще всего удалить процесс командой DROP PROCESS
добавив id удаляемого процесса.
Сделать всё это можно и при помощи менеджеров СУБД. Например, в phpMyAdmin нужно выйти на главную и в навигации сверху нажать на пункт «процессы», ну или на «состояние» и на странице состояния работы сервера так же будет отображена таблица с текущими процессами для пользователя.
Вообще конечно ситуации при которой забивается очередь процессов надо избегать. Т.е. перед отправкой запроса серверу надо проверить очередь и сравнить с максимально допустимым лимитом и только после этого делать свой запрос если на это возможно, либо применять меры по очистке очереди процессов, ну или просто подождать. Естественно делать всё это при каждом запросе абсурд, поэтому подобными проверками, по моему мнению, должен заниматься коннектор БД, своеобразная прослойка между кодом программы и предоставляемым языком API СУБД.