Добрый день. Есть 3 таблицы, связанные между собой внешними ключами.

получается вот так:

В таблице t1_to_t2 - связь таблиц t1 и t2. Хочется, что бы при удалении записи в t1 удалялись соотв. записи в остальных. Всё так и работает, кроме досадной мелочи: после удаления в t1_to_t2 остаются хвосты. Например, если удалить из t1 запись с id=1, то в t1_to_t2 останутся строки:

Можно ли решить эту проблему исключительно с помощью внешних ключей?

А сфига бы должны удаляться записи с t1_id, НЕ равными t1.id удаляемой записи?

отсюда и вопрос, как сделать красиво...

Все лишние записи из t1_to_t2 после этого удалятся.

смешно. Тогда уже сразу TRUNCATE t1_to_t2

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

Что значит красиво ?
Почему из таблицы t1_to_t2 должны удалится строки с t2_id=1 при удалении из таблицы t1 записи с id=1 ?

А ключи наверное нужно так

Ещё раз спрашиваю. 
Почему при удалении из t1 строки с t1.id=1 должны из t1_to_t2 удаляться строки с t1_id=2 и t1_id=3?

объясню на рабочем примере.

в таблице t1 находятся некие правила
в таблице t2 находятся определённым образом обработанные тексты; обработка осуществляется с использованием правил из t1. Информация о том, какие правила использовались для обработки  каждой конкретной записи в t2 находится в таблице t1_to_t2. 

В данном примере в таблице t2:
для id=1 используются записи id=1,2,3 из t1;
для id=2 используются записи id=4,5,6 из t1;
для id=3 используются записи id=7,8,9,10 из t1;

задача: при удалении правила из t1 так же удалять обработанные этим правилом тексты из t2, и так же удалять записи в связующей таблице t1_to_t2

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

Вы не понимаете сути референсных действий.

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

А т.к. у тебя

то задача нерешаема.

Добавлено через 1 минуту и 9 секунд
Для обеспечения требуемого уровня поддержания целостности следует изолировать таблицы от клиента, и все действия по изменению (в данном случае удалению) данных выполнять через хранимую процедуру, которая реализует требуемую логику каскадного действия.

я так и сделал, только не процедурой, а триггером

Триггер - не очень хорошо. Не каждая операция изменения данных вызывает срабатывание триггера. И будешь потом гадать, почему всё развалилось...

Мне надо что-то делать только при удалении. Какие могут быть проблемы?

Такие же, как и сейчас - не-удаление связанных записей.

Решения вижу два.
Первое - уже озвученное, вынести логику в хранимую процедуру.
Второе - убрать каскадные операции, и выполнять удаление записей, потерявших связи, служебной процедурой по эвенту. Да, при этом в период с момента удаления до момента выполнения процедуры эвента в таблицах будут присутствовать "зависшие" записи, но логика запросов на получение данных не должна выбирать их в выходные наборы.

понятно, спасибо, учту