В MySQL закрыли 20-летний баг: его нашли в 2005 году, но очень долго не исправляли

Команда MySQL закрыла один из самых известных багов-долгожителей. Тикет для ошибки завели ещё летом 2005 года, но не исправляли. На этом фоне пользователи иронично шутили, поздравляя баг каждый год с днём рождения и отмечая, сколько жизненных этапов удалось уже пройти за время его существования.

Суть ошибки заключалась в том, что при каскадных изменениях через внешние ключи 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.

— Что?! Но кому мы теперь будем покупать торт каждый год… Я чувствую себя потерянным.