Как убить соединение mysql после «upstream timed out»

nginx никого не грохает, он только обрабатывает сетевые соединения.

mysql запросы, которые были отправлены ранее, продолжают выполняться, потому что соединение не было закрыто в конце скрипта как положено

Потому что конец скрипта ещё не наступил. То что nginx не дождался от него ответа - это дело nginx-а, а скрипт как работал так и работает, причин неожиданно завершаться у него нет.

Если хочешь таймаут на выполнение скрипта то прописывай его (таймаут) в настройках пхп. В php.ini есть max_execution_time но оно работает на логическом уровне интерпретатора, и есть таймаут в php-fpm.conf request_terminate_timeout который принудительно убивает процесс.

nginx никого не грохает, он только обрабатывает сетевые соединения

грохает соединение с socket php-fpm, запрос уничтожается

Я про это

upstream timed out (110: Connection timed out) while reading response header from upstream

Повторю ещё раз, nginx занимается проксированием клиентских соединений к пхп, управлением самим пхп он ни в каком виде не занимается. Запрос уже запущен и продолжит выполняться, наличие соединения к php-fpm роли тут никакой не играет. Про запросы к mysql nginx тем более ничего не знает, это всё дело пхп - в нём и настраивай.

Настройку

fastcgi_read_timeout 3s;

лучше убрать, 3 секунды тут это настройка в целом неадекватная, если только у тебя не что-то особенное. Нормальные значения от 10 секунд. И на всякий случай ещё раз повторю, это ни коим образом не таймаут на работу скрипта, это таймаут на ожидание данных из сокета и отправку их клиенту.

Да, ты прав. Не убивает таки. Нарыл request_terminate_timeout в пхп, вроде это спасет

Нарыл request_terminate_timeout

А мог бы просто прочесть первый же мой ответ:

есть таймаут в php-fpm.conf request_terminate_timeout который принудительно убивает процесс.