Карта решений:
от 504 до SQL. Decision map:
from 504 to SQL.

Сначала — граница тайм-аута

Во внешнем прокси не было ошибок соединения, а внутренний Nginx каждый раз обрывал ожидание через одинаковый промежуток. В журнале стояло upstream timed out; TLS, DNS и передача запроса между площадками к этому моменту уже отработали.

Apache завершал тот же запрос значительно позже. Один отчёт работал около часа, тогда как Nginx ждал ответ 200 секунд. Поэтому 504 возникал на Nginx, но причиной не был сам Nginx: он лишь первым достиг своего предела ожидания.

• 200сграница ожидания Nginx до первого 504
• ≈65минвремя первого запроса в Apache и MariaDB
• ≈50тыс.строк вернул запрос отчёта
• >5млрдстрок просмотрено по slow log

Почему тайм-аут получили даже простые запросы

Первый тяжёлый запрос удерживал PHP-сессию. Следующие обращения того же браузера вставали за её блокировкой: проверка состояния, переход на соседнюю страницу и даже запрос значка сайта. Когда долгий отчёт завершился, накопившиеся обращения закончились почти одновременно.

Это объяснило странную картину в журналах. Простые адреса не были медленными сами по себе; они принадлежали одной пользовательской сессии и ждали освобождения блокировки. Публичные страницы и запросы других посетителей могли продолжать работать.

Запрос, который держал цепочку

Отчёт выбирал клиентов и для каждого отдельно искал последний заказ. В упрощённом виде запрос выглядел так:

SELECT c.*,
       (
         SELECT o.created_at
         FROM orders o
         WHERE o.customer_id = c.id
         ORDER BY o.id DESC
         LIMIT 1
       ) AS last_order_at
FROM customers c
WHERE c.is_active = 1 OR c.order_count > 0
ORDER BY c.last_name;

На старой версии MariaDB коррелированный подзапрос повторял поиск для десятков тысяч клиентов. Журнал медленных запросов показал полное сканирование и сортировку на диске. Одиночный индекс по customer_id уже существовал, но оптимизатор выбирал первичный ключ и проходил по нему снова и снова.

Индекс без плана — ещё не исправление

Составной индекс (customer_id, id, created_at) подходил для поиска последней записи и мог покрыть подзапрос. Но контрольный EXPLAIN показал, что старая MariaDB не выбирает его автоматически. Подсказка FORCE INDEX меняла план на точечный поиск, однако связывала код с наличием индекса во всех новых и существующих схемах.

Постоянное исправление должно попасть в один релиз: миграция создаёт индекс, код использует проверенный план либо уходит от коррелированного поиска, а тесты проверяют и результат, и план. Временный индекс, созданный при проверке, не оставлялся как незадокументированная часть производственной схемы.

Что карта отбрасывает

1. Перезапустить всё. Это могло освободить занятый обработчик, но не объясняло причину и не меняло план медленного SQL-запроса.
2. Увеличить ожидание прокси. Пользователь ждал бы дольше, число занятых обработчиков росло бы, а запрос продолжал просматривать миллиарды строк.
3. Считать все 504 одним инцидентом. В общих журналах были другие тайм-ауты. К этому разбору относились только записи с совпадающими временем, сессией и цепочкой внутренних запросов.
4. Оставить ручной DDL. Постоянное изменение схемы относится к миграциям приложения; иначе следующая база или восстановление из шаблона вернёт старое поведение.

Порядок проверки после исправления

• открыть тот же отчёт на данных сопоставимого объёма;
• сверить EXPLAIN: точечный доступ по составному индексу вместо прохода по первичному ключу;
• убедиться, что запрос не появляется в slow log и не удерживает PHP-сессию;
• проверить отсутствие новых upstream timed out и рост занятых обработчиков;
• закрепить порог времени отчёта и число просмотренных строк в наблюдаемости.