Суть ошибки заключалась в том, что при каскадных изменениях через внешние ключи MySQL обновлял строки в дочерних таблицах, но не запускал для них триггеры. Например, если в родительской таблице удаляли запись, то в дочерней таблице срабатывал ON DELETE SET NULL или ON DELETE CASCADE, и данные в ней действительно менялись. При этом триггер AFTER UPDATE или AFTER DELETE, который разработчик ожидал увидеть при таком изменении, не запускался.
Разработчики отмечают, что это давнее архитектурное ограничение MySQL. Всё из-за того, что каскадные операции внешних ключей выполняются внутри InnoDB, а триггеры находятся на SQL-уровне. Возможность исправить этот баг появилась только в MySQL 9.6, когда команда перенесла обработку внешних ключей на SQL-уровень.
Новое поведение по умолчанию выключено, а для активации предусмотрена переменная enable_cascade_triggers. Разработчики просят внедрять опцию внимательно. Если приложение годами нормально работало без запуска триггеров при каскадных изменениях, то активация опции может изменить результаты операций и нарушить логику.
Баг исправили ещё в марте 2026 года, но пользователи заметили фикс только сейчас. В комментариях на Reddit продолжают шутить о возрасте бага. Вот некоторых из комментариев:
— Я не думал, что доживу до этого момента!
— Боже мой, у меня в календаре реально отмечен день рождения этого бага, чтобы не забывать отмечать его. Спасибо разработчикам, что исправили его.
— Наконец-то! Я ждал пока они пофиксят это, чтобы я смог перенести свою базу данных из Excel в MySQL.
— Что?! Но кому мы теперь будем покупать торт каждый год… Я чувствую себя потерянным.
