pymysql调用存储过程需用callproc()方法，输入参数直接传入，输出参数需通过查询@_procname_n临时变量获取，多结果集须配合multi_query()等手动处理。
CALL 语句本身不难，真正卡住人的从来不是语法，而是「调用后没结果」「参数传不进去」「OUT值拿不到」——这些问题背后是 MySQL 协议层、PHP 扩展行为、存储过程定义三者之间的隐式耦合。
为什么 mysqli->query("CALL proc()") 只能取到第一个结果集？
因为 query() 是单结果集接口，而存储过程可能返回多个结果集（比如内部有多个 SELECT）、还可能带 OUT 参数或影响行数。MySQLi 默认只暴露第一个结果，后续的被“堵”在连接缓冲区里。
- 必须改用
multi_query()+ 循环store_result()+next_result() -
store_result()必须在next_result()后立即调用，否则返回null - 漏掉
next_result()就永远卡在第一个结果，后续结果无法读取 - 如果过程只有一条
SELECT，query()看似能跑通，但加个日志或统计语句就崩
PDO::prepare("CALL ...") 绑定 OUT 参数为什么总为空？
PDO 不自动识别 OUT 参数，它只把占位符当输入用。你得手动告诉它：“这个变量要双向流动”，而且变量本身必须提前声明、不能是字面量。
- 必须用
bindParam()，不能用bindValue() - 类型标识要带上
PDO::PARAM_INPUT_OUTPUT，比如PDO::PARAM_INT | PDO::PARAM_INPUT_OUTPUT - 变量需提前初始化：
$total = 0;，否则绑定失败 - 长度参数（如第四个参数
20）必须 ≥ 存储过程中定义的OUT参数长度，否则值被截断 - MySQL 5.7 和 8.0 对
CALL后分号处理不同：5.7 常需$$结尾，8.0 可直接用;
存储过程里有 SELECT，PHP 却 fetch 不到数据？
这不是 PHP 漏了，是 MySQL 的协议设计：过程体内的 SELECT 生成的是“结果集流”，PHP 不会自动把它塞进某个变量里。你得显式去捞，或者换路子。
- 若只想取一个标量（如计数），用
OUT参数 + 用户变量：CALL CountUsers(@c); SELECT @c;，再执行第二条查询 - 若要取表格数据，PDO 需调用
nextRowset()（注意：phpEnv 默认未启用 mysqlnd 时该方法不可用） - mysqli 必须走
multi_query()路线，且每次next_result()后都要store_result() - 别在过程里写
SELECT COUNT(*) FROM t; SELECT * FROM t;然后指望 PHP 一次全拿到——它不会合并，只会按顺序暴露
DELIMITER 报错 ERROR 1064 怎么办？
DELIMITER 不是 SQL，是 MySQL 客户端命令。你在 phpMyAdmin、命令行里执行没问题，但直接扔进 PHP 的 query() 就会炸，因为 PHP 发送的是纯 SQL 流，不解析客户端指令。
- 建过程语句不能直接用 PHP 执行，必须在数据库客户端（如 phpMyAdmin SQL 标签页）中运行
-
DELIMITER //必须放在CREATE PROCEDURE之前，DELIMITER ;必须放在之后，否则后续所有语句都失效 - Navicat 等工具需手动开启“允许自定义分隔符”选项；phpEnv 自带的 phpMyAdmin 默认支持
- 建完立刻查：
SHOW PROCEDURE STATUS LIKE 'proc_name';，确认状态为Valid
实际调用时最易忽略的一点：存储过程里的事务控制和 PHP 层的 beginTransaction() 是两套逻辑，互不感知。你在过程里写了 START TRANSACTION，PHP 抛异常也不会触发它的 ROLLBACK，除非过程内自己加了 DECLARE EXIT HANDLER FOR SQLEXCEPTION。更稳的做法，是让存储过程只做纯逻辑，事务由 PHP 层统一兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
