MySQL不支持面向对象，但可用存储过程模拟业务逻辑封装：通过IN/OUT参数、事务控制、异常处理实现可复用、边界清晰的原子操作，如“下单并扣库存”。
MySQL 本身不支持面向对象（没有类、继承、封装等概念），所谓“面向对象封装”在 MySQL 里是伪命题——你不能像 Python 或 Java 那样定义类、实例化对象、调用方法。但你可以用 存储过程 + 参数校验 + 事务控制 + 错误处理 模拟出“业务逻辑封装”的效果。关键不是“面向对象”，而是“可复用、可维护、边界清晰”。
存储过程怎么写才像一个业务单元
把一段常被多处调用、涉及多表操作、需保证原子性的逻辑，抽成一个带明确输入/输出的 PROCEDURE。它不是函数（不返回值），但可通过 OUT 参数或临时表/结果集传递结果。
-
IN参数用于传入业务主键、状态码、金额等必要条件；避免直接拼接字符串传 SQL 片段 - 开头加
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获异常，配合ROLLBACK保事务安全 - 所有 DML 操作前加注释说明业务意图，例如：
-- 扣减用户余额，失败则中断整个流程 - 不依赖外部变量（如
@user_id），全部通过参数传入，否则无法跨会话复用
常见错误：把存储过程当黑盒函数乱调用
典型表现是：调用方不检查 OUT 参数、忽略 SQLSTATE、没设超时、在应用层重复开启事务。这会让“封装”变成“隐藏风险”。
- 调用前必须确认
autocommit=0，否则START TRANSACTION在过程内无效 - 过程里不要用
SELECT返回非业务结果（如调试用的SELECT 'debug'），会被客户端误当成主结果集 - 避免在过程中执行耗时操作（如大表
UPDATE不加LIMIT、无索引JOIN），否则阻塞其他调用 -
CALL proc_name(@in_id, @out_status); SELECT @out_status;是标准调用链，漏掉SELECT就看不到结果
用例：封装一个「下单并扣库存」原子操作
这是最典型的业务封装场景。注意它必须包含：库存校验 → 创建订单 → 扣减库存 → 错误回滚。下面是一个精简但可用的版本：
DELIMITER $$
CREATE PROCEDURE sp_create_order(
IN p_user_id INT,
IN p_item_id INT,
IN p_quantity INT,
OUT p_order_id BIGINT,
OUT p_result_code VARCHAR(20)
)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
SET p_result_code = 'ERROR';
END;
<pre class='brush:php;toolbar:false;'>START TRANSACTION;
-- 校验库存是否充足
IF (SELECT stock FROM items WHERE id = p_item_id) < p_quantity THEN
SET p_result_code = 'INSUFFICIENT_STOCK';
ROLLBACK;
LEAVE proc_label;
END IF;
-- 创建订单
INSERT INTO orders (user_id, status) VALUES (p_user_id, 'created');
SET p_order_id = LAST_INSERT_ID();
-- 扣减库存
UPDATE items SET stock = stock - p_quantity WHERE id = p_item_id;
SET p_result_code = 'SUCCESS';
COMMIT;END$$ DELIMITER ;
调用方式：CALL sp_create_order(123, 456, 2, @oid, @rc); SELECT @oid, @rc;
为什么不用函数而用存储过程
FUNCTION 只能返回单个值，且不能含 COMMIT/ROLLBACK、不能修改表（除非是 READS SQL DATA 且仅查）、不能调用存储过程。而真实业务几乎都需“读+写+事务”，所以 PROCEDURE 是唯一选择。
-
FUNCTION适合纯计算（如FORMAT_PRICE(price)），或只读查询（如GET_USER_NAME(id)） - 若硬要用
FUNCTION做业务逻辑，会触发ERROR 1418（未声明DETERMINISTIC等特性）或ERROR 1422（不允许在函数中修改数据） - MySQL 8.0+ 支持
RETURN类型函数，但依然绕不开上述限制
真正难的不是写出来，是让每个存储过程有明确职责边界、参数含义自解释、错误码可追溯、性能不拖垮主库。别为了“封装”而封装，先想清楚这个逻辑是不是真的需要数据库层兜底。
