✅为什么不建议使用存储过程？

典型回答

存储过程是一种在数据库中存储的预编译的代码块，它可以执行一系列的数据库操作。存储过程被设计用来完成特定的功能或业务逻辑，通常是一组SQL语句的集合。

假设我们有一个名为 Employees 的数据库表，其中包含员工的基本信息，如员工ID、姓名和薪水。我们想创建一个存储过程来更新特定员工的薪水。以下是一个在MySQL中实现这个功能的存储过程示例：

DELIMITER //

CREATE PROCEDURE UpdateEmployeeSalary(IN empID INT, IN newSalary DECIMAL(10,2))
BEGIN
    -- 检查新薪水是否大于0
    IF newSalary > 0 THEN
        -- 更新员工的薪水
        UPDATE Employees SET salary = newSalary WHERE employee_id = empID;
    ELSE
        -- 如果薪水无效，则抛出错误
        SIGNAL SQLSTATE '45000'
        SET MESSAGE_TEXT = 'Invalid salary amount';
    END IF;
END //

DELIMITER ;

这个存储过程名为 UpdateEmployeeSalary，接受两个参数：empID（员工ID）和 newSalary（新薪水）。它首先检查新薪水是否为正数，如果是，则更新对应员工的薪水。如果薪水不合理（例如，小于或等于0），则抛出一个错误。

要调用这个存储过程，可以使用以下SQL命令：

CALL UpdateEmployeeSalary(123, 50000.00);

但是，其实在现在的很多大型互联网应用中，存储过程用的已经非常少了。拿我自己来说，我其实从来都没有在生产环境中真正的使用过存储过程。

之所以很少用，是因为存储过程存在以下几个问题或者局限性：

可维护性：存储过程的逻辑可能是非常复杂的，随着内容的不断修改，会变的难以理解和维护。
调试和测试困难：与应用程序代码相比，存储过程的调试和测试是非常困难的。他不像业务代码一样我们可以打日志、加断点、写单测等进行非常方便的调试。
跨数据库兼容性：存储过程通常不是跨数据库平台兼容的。这意味着如果你从一个数据库系统（如MySQL）迁移到另一个（如PostgreSQL），可能需要重写所有存储过程。这会导致迁移工作量增加，并增加对特定数据库的依赖。
容易出错：用到存储过程的场景，都是非常复杂的业务场景，里面会有很多很多业务逻辑，这些业务逻辑在存储过程中通过各种IF-ELSE分支来实现的话，非常容易出错。
安全性问题：存储过程可能成为安全风险的源头，特别是如果它们不正确地处理输入数据，可能导致SQL注入等安全漏洞。此外，过度依赖存储过程可能会导致数据库权限和访问控制变得复杂。
版本控制和源代码管理：存储过程的代码通常存储在数据库中，这可能使得将它们纳入常规的源代码管理和版本控制流程变得更加困难。
代码审查：如果是业务逻辑写在代码中，很多时候CodeReview的时候都会非常重点的关注，但是对于SQL语句，有的时候就很容易被忽略，那么很多问题就不容易被暴露出来。

一般来说，比较常见的做法是不使用存储过程，而是直接在应用程序中实现业务逻辑。这可以通过任何服务器端编程语言完成。这种方式提高了代码的可移植性和可维护性，因为应用程序代码通常更易于管理和部署。

原文: https://www.yuque.com/hollis666/xkm7k3/ynztvs5ybexqof8s