MySQL原生不支持调用HTTP接口，存储过程无法发起网络请求，需依赖UDF插件（如lib_mysqludf_sys）间接执行curl命令，或移至应用层实现；FEDERATED/CONNECT引擎仅支持有限外部数据映射，非真正HTTP调用。
MySQL原生不支持调用HTTP接口
直接回答：MySQL存储过程本身无法发起网络请求，SELECT、INSERT这些语句不带网络能力，也没有内置的curl或http_get函数。所谓“调用外部系统接口”，必须靠插件或绕过MySQL执行层来实现。
常见错误现象是有人在存储过程中写SELECT http_get('https://api.example.com')，结果报错FUNCTION http_get does not exist——这不是语法写错了，是函数根本不存在。
- MySQL 8.0+ 仍不提供任何官方HTTP客户端函数
- 社区有
lib_mysqludf_sys这类UDF插件，但只支持执行系统命令，不能直接发HTTP（得靠curl或wget命令间接实现） - 真正稳定的做法是把“调用逻辑”移出MySQL，由应用层或调度任务（如Python脚本 + 定时器）完成
用UDF插件执行shell命令调用API（仅限Linux + 有root权限）
这是最接近“在存储过程中调用接口”的方案，本质是让MySQL执行curl命令，再把输出读回来。但限制极多，不是通用解法。
使用场景：内网封闭环境、临时调试、无应用层改造权限、且DBA允许安装自定义UDF。
- 需先编译安装
lib_mysqludf_sys，注册sys_exec和sys_eval函数 -
sys_exec('curl -s https://httpbin.org/get')只能返回命令退出码（0或非0），拿不到响应体 - 要用
sys_eval('curl -s https://httpbin.org/get')才能拿到响应文本，但它会把换行符转成\n字符串，解析JSON很麻烦 - MySQL用户必须有
FILE权限，且secure_file_priv不能为NULL或空值，否则sys_eval直接失效 - 性能差：每次调用都fork新进程，高并发下容易打满服务器资源
更现实的替代方案：用FEDERATED引擎或外部表桥接
如果目标系统提供MySQL兼容协议（比如某些云数据库、PostgreSQL配了mysql_fdw），可以用FEDERATED或CONNECT引擎把远端数据“映射”成本地表，再用SELECT查——看起来像调用接口，实则是走SQL协议。
但注意：这不等于调用REST API，只是把另一个数据库当“表”用。
-
FEDERATED引擎在MySQL 8.0.23后被标记为deprecated，新部署不建议启用 -
CONNECT引擎（MariaDB原生支持，MySQL需额外编译）能连HTTP，但只支持GET且只认CSV/JSON格式，字段名、嵌套结构、认证都受限 - 例如配置一个
CONNECT表指向https://api.example.com/data.csv，然后SELECT * FROM api_csv_table——它背后是定期拉取并缓存，不是实时HTTP调用
为什么不该在存储过程中硬上HTTP调用
这不是技术能不能的问题，而是职责错位。MySQL负责数据持久化与一致性，网络I/O、超时控制、重试策略、证书管理、鉴权刷新这些事，它既没设计也没能力管好。
- 一次HTTP超时可能卡住整个存储过程，进而阻塞事务，影响其他查询
- 错误处理极其有限：
sys_eval失败时只返回NULL，没法区分是DNS失败、连接拒绝还是HTTP 500 - 日志不可追溯：curl输出进不了MySQL error log，debug时只能看
strace或临时文件 - 安全风险高：一旦UDF被注入恶意命令（比如拼接用户输入），就等于给攻击者开了
rootshell
真正需要同步触发外部动作的场景，应该用应用层发消息到队列（如RabbitMQ/Kafka），再由独立服务消费并调用API——链路清晰、可监控、可重试、不拖慢数据库。
