Можно ли выдать (дорогой, но низкоприоритетный) запрос SELECT к mySQL таким образом, что если в очереди появится запрос UPDATE, mySQL немедленно завершит запрос и повторно добавит его в конец очереди ?
Если повторное добавление в очередь невозможно, я могу просто убить запрос SELECT.
Нет, не совсем.
Я не уверен точно, что вам нужно, но я предполагаю, что вам нужно либо оптимизировать SELECT, чтобы не блокировать всю таблицу, либо запустить репликацию и выполнить SELECT на ведомом, а не на ведущем.
Теоретически вы можете узнать, какой идентификатор процесса MySQL имеет запрос SELECT, и в своем приложении отправить KILL, прежде чем выполнять какое-либо обновление.
Ну типа может быть.
Клиент запускает приложение, которое время от времени выдает запросы, которые полностью убивают производительность всего остального на сервере. У нас есть мониторинг, и если у нас есть подходящий человек, готовый отреагировать, мы можем обработать этот запрос вручную и узнать о проблемах в приложении, действуя таким образом.
Но чтобы предотвратить серьезные сбои, если никто не вмешивается, у нас есть автоматизированный сценарий, который завершает длительные запросы, поэтому сервер восстанавливается, если никто не может вмешаться в течение 15 минут.
Далеко от идеала, но в настоящее время дела обстоят именно так с этим проектом, и он действительно предотвращает случайные длительные сбои, которые происходили раньше. Мы можем двигаться так быстро только с исправлением проблемных запросов.
Во всяком случае, вы можете запустить что-то подобное, которое просматривает запущенные запросы и распознает, когда у вас есть обновление, ожидающее одного из ваших больших выборок, и в этом случае он убивает выбор. Выполнение такой проверки несколько раз в минуту не слишком дорого. Я хотел бы сделать небольшое тестирование перед запуском.
Таким образом, сможете ли вы решить свою проблему таким образом, зависит от вашей терпимости к тому, как долго может быть отложено обновление. Запускать это каждую минуту (как и мы) не проблема. Запуск его каждую секунду заметно увеличит общую нагрузку. Вам нужно будет проверить, насколько далеко вы можете разумно зайти между этими точками.
Этот подход означает некоторую задержку перед тем, как выбор будет вытеснен, но избавляет вас от необходимости встраивать эту логику в потенциально много разных мест в вашем приложении.
--
Что касается разделения вашего запроса, вам, скорее всего, лучше ограничить фрагменты диапазоном идентификаторов из одной или нескольких таблиц в вашем запросе, а не смещением и пределом.
--
Также могут быть хорошие решения, основанные на разделении ваших таблиц, чтобы запросы не конфликтовали так сильно. Убедитесь, что вы очень хорошо понимаете, что вы делаете для этого.
