为什么大家都不推荐使用MySQL触发器而用存储过程？

Question

不止一次在各大论坛，文章中看到大多数人不推荐触发器，统统推荐存储过程。这是为什么呢？
现在的场景是：1000万数据，1万并发的规模。疑问：
我的理解是：
触发器本身就是特殊的存储过程，那么如果业务逻辑本身不需要定义变量，不需要定义事务，仅仅需要for each row /update/delete/insert，仅仅需要触发器的情况下，还要特定使用存储过程吗？

还是说触发器本身具有特别大的性能问题呢？

Answer 1

1. ストアド プロシージャとトリガーは密接に関連しています。トリガーはパラメーターや明示的な呼び出しを必要とせず、多くの場合、知らないうちに使用されるため、隠蔽されたストアド プロシージャであると私は考えています。ケース内で完成しました。この観点から見ると、データベースは非表示であるため、データベースが実行されなければ存在しないため、システムの複雑さが増します。
2. さらに、複雑なロジックが含まれる場合、トリガーのネストが避けられず、トランザクションなどと組み合わせて複数のストアド プロシージャが関与すると、デッドロックが発生しやすくなり、1 つのトリガーから切り替えることがよくあります。連鎖的な関係を継続的に追跡すると、人々は簡単に頭が痛くなります。実際、パフォーマンスの観点から見ると、トリガーによってパフォーマンスはあまり向上しませんが、コードの観点から見ると、コーディング中にビジネスを実装するのが簡単になる可能性があるため、私の見解は「トリガーを放棄する!」です。基本的に、トリガーの機能はストアド プロシージャを使用して実装できます。
3. コーディングにおいて、ストアド プロシージャの明示的な呼び出しが行われるとコードが読みやすくなり、トリガーの暗黙的な呼び出しが無視されやすくなります。
ストアド プロシージャにも致命的な欠陥があります↓
4. ストアド プロシージャの移植性は、たとえば、ストアド プロシージャが mysql データベースに保存されている場合に移植する必要があることです。パフォーマンスを考慮して Oracle に移植した場合、すべてのストアド プロシージャを書き直す必要があります。

Answer 2

使用しないことをお勧めします。

この種のものは、同時実行性の低いプロジェクトや管理システムでのみ使用されます。

ユーザー指向の同時実行性の高いアプリケーションの場合は、使用しないでください。

トリガーとストアド プロシージャ自体は開発と保守が難しく、効率的に移植することはできません。

トリガーはトランザクションに完全に置き換えることができます。
ストアド プロシージャはバックエンド スクリプトで置き換えることができます。

Answer 3

これは 2 つの要因から来ていると思います。
1- ストアド プロシージャを明示的に呼び出す必要があります。つまり、ソース コードを読むときにストアド プロシージャの存在を知ることができますが、トリガーは実行時に確認する必要があります。無視されがちなデータベース側。
2- Mysql のトリガー自体があまり良くなく、削除後の連鎖反応ができないなどの問題があります。
性能的には実はビーチサンダルの方が有利だと思いますが、上記の理由であまり好まれません。