mysql存储过程本身无法直接与其他数据库交互，所谓“交互”必须通过应用层中转或借助有限的系统级能力；这是安全模型的必然约束，而非设计缺陷。
MySQL 存储过程本身不能直接访问外部数据库或调用网络服务，所谓“交互”必须通过应用层中转或借助有限的系统级能力——这不是设计缺陷，而是安全模型的必然约束。
Java 应用调用存储过程时参数绑定容易出错
常见错误是 CallableStatement 中占位符与参数顺序/类型不匹配，比如把 OUT 参数声明为 IN，或未在执行前调用 registerOutParameter()。
- 输入参数用
setString(1, "value")，输出参数必须先registerOutParameter(2, Types.VARCHAR)再execute() - 如果存储过程有多个
OUT或INOUT参数，顺序必须严格对应CALL proc(?, ?, ?)中的问号位置 - 使用
getResultSet()获取结果集前，要确认存储过程确实返回了游标（即含SELECT语句），否则会返回null
Python 调用时连接池与事务边界易混淆
用 pymysql 或 mysql-connector-python 调用存储过程时，事务不会自动跨存储过程延续——即使你在 Python 中开启了 autocommit=False，存储过程内部的 COMMIT 或 ROLLBACK 仍会立即生效。
- 避免在存储过程中写
COMMIT，除非你明确需要分段提交；否则由 Python 控制整个事务生命周期 - 连接池（如
DBUtils.PooledDB）返回的连接，调用完存储过程后必须显式close()或用with管理，否则可能耗尽连接 - 若存储过程含多个
SELECT，需用cursor.nextset()跳转到下一个结果集，否则只读取第一个
C++ 使用 MySQL C API 时内存泄漏风险高
mysql_use_result() 和 mysql_store_result() 的选择直接影响资源释放逻辑：前者流式读取但必须调用 mysql_free_result()，后者缓存全部结果但更占内存。
- 调用存储过程后，必须用
mysql_next_result(conn)检查是否有更多结果集（尤其当过程含多个SELECT或OUT参数） -
mysql_stmt_bind_param()绑定参数时，MYSQL_BIND::buffer必须指向有效内存，且length字段要随字符串长度动态更新 - 错误处理不能只依赖
mysql_error()，还要检查mysql_stmt_errno()——预编译语句失败时前者可能为空
真正需要“跨库交互”的场景，几乎都该放弃在存储过程中硬编码外部连接逻辑。把数据拉到应用层，用 Go/Python/Java 做协调，比依赖 sys_exec() 或虚构的 external_link() 函数更可控、可测、可运维。
