公式には、カスケード操作の順序を制御することはできません。 文書化されていない一部を悪用できる可能性があります ただし、動作：
- MySQL 5.5の場合、外部キーは作成された順序で実行されるため、
fk_category_orgを削除して再作成します。 -制約は機能するはずです - MySQL 5.6以降の場合、外部キーは名前の辞書式順序で実行されるため、名前を
fk_category_orgに変更します。 例：fk_z_category_org動作するはずです
これは文書化されておらず、いつでも変更される可能性があります（他の要因の影響を受ける可能性があります）。
そうは言っても、これを行うための適切な方法（およびon cascadeには複雑すぎる他の方法 ）before deleteを追加します -トリガー
organisation -最初にユーザーを「手動で」削除し、その後にカテゴリを削除するテーブル。 before delete -トリガーはon cascadeの前に実行されます （したがって、誤解を招く可能性がありますが、それらを保持するかどうかを決定できます）。
それが意図した動作であるかどうかは完全には明らかではありませんが、現在、ユーザーは組織2に割り当てられている間、組織1に属するカテゴリを持つことができます。組織1を削除しても失敗します。設計上、それを防ぎたいように見えますが、この場合も削除を機能させたい場合は、必要 トリガーを使用してそれを組み込む（またはアプリケーションで手動で削除する）には、カテゴリテーブルでもカスケードしない限り、カスケードは機能しません。