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

Question

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

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

Answer 1

1. Stored procedures and triggers are closely related. My general understanding is that a trigger is a hidden stored procedure, because it does not require parameters or explicit calls, and is often used without your knowledge. A lot of operations have been done in the case. From this perspective, because it is hidden, it virtually increases the complexity of the system. Non-DBA personnel will have difficulty understanding the database because it does not exist at all if it is not executed.
2. Furthermore, when complex logic is involved, nesting of triggers is unavoidable. If several stored procedures are involved, coupled with transactions, etc., deadlocks will easily occur. Debugging Sometimes, you will often switch from one trigger to another. The continuous tracing of cascading relationships can easily make people's heads ache. In fact, from a performance perspective, triggers do not improve performance much, but from a code perspective, it may be easy to implement business during coding, so my point of view is: abandon triggers! Basically, the functions of triggers can be implemented using stored procedures.
3. In coding, it is easy to read the code when the stored procedure display call is made, and the implicit call of the trigger is easy to be ignored.
Stored procedures also have their fatal flaws↓
4. The fatal flaw of stored procedures is portability. Stored procedures cannot be transplanted across databases. For example, if a stored procedure is previously stored in a MySQL database, it needs to be transplanted to Oracle considering performance. All stored procedures need to be rewritten.

Answer 2

I suggest not to use it at all.

This kind of thing is only used in projects and management systems with low concurrency.

If it is a user-oriented high-concurrency application, do not use it.

Triggers and stored procedures themselves are difficult to develop and maintain, and cannot be efficiently ported.

Triggers can be completely replaced by transactions.
Stored procedures can be replaced with back-end scripts.

Answer 3

I think it comes from two factors:
1- The stored procedure needs to be called explicitly, which means that you can know the existence of the stored procedure when reading the source code, but the trigger must be seen on the database side, which is easy to be neglect.
2- Mysql's trigger itself is not very good, such as the problem that after delete cannot have a chain reaction.
I think triggers actually have the advantage in terms of performance, but they are not favored for the above reasons.