存储过程不能被HTTP请求直接调用，必须通过应用服务封装或极少数数据库HTTP网关转发；所有“API调用存储过程”实为应用层执行SQL再返回JSON。
存储过程不能直接被 HTTP 请求调用
SQL 存储过程本身不暴露网络接口，外部程序（如 Python、Node.js 或前端）无法绕过数据库驱动直接用 API 调用 sp_get_user_orders 这类过程。必须通过中间层转发——要么走应用服务封装，要么用数据库自带的 HTTP 网关（极少数支持，如 SQL Server 的 REST API 扩展，但生产环境几乎不用）。
常见错误现象：404 Not Found 或 Connection refused，本质是试图把 http://localhost:5000/sp_get_user_orders 当成真实端点，而它根本不存在。
- 所有“API 调用存储过程”的说法，实际指「应用层代码执行 SQL 调用」，再把结果序列化为 JSON 返回
- 不要在 API 路由名里硬塞存储过程名，比如
/api/sp_update_inventory容易误导维护者以为后端直连了 SP - 若用 ORM（如 SQLAlchemy、TypeORM），注意禁用自动查询构建，改用
text()或raw()执行EXEC sp_update_inventory @id=123
参数传递必须严格匹配存储过程定义
SQL Server 的 sp_executesql、MySQL 的 CALL、PostgreSQL 的 SELECT * FROM my_procedure(...) 对参数类型、顺序、空值处理差异极大。传错一个 NULL 或把 INT 当 VARCHAR 传，过程可能静默失败或报 Conversion failed。
使用场景：前端提交 { "user_id": "abc" }，后端没校验就塞进 @user_id INT 参数 → 直接触发 SQL Server 错误 Msg 245, Level 16。
- SQL Server：用
SqlParameter显式指定SqlDbType.Int，别依赖隐式转换 - MySQL：
CALL my_proc(?, ?)占位符必须与IN/OUT参数个数完全一致，少一个就报Incorrect number of arguments - PostgreSQL：函数需声明为
RETURNS TABLE或SETOF，否则SELECT * FROM sp_name()会报ERROR: function sp_name() does not exist
输出结果集结构不稳定时，API 层必须做归一化
存储过程可能返回多个结果集（SQL Server 支持；MySQL 不支持）、列名含空格或大小写混用（"User Name"）、甚至动态列（PIVOT 场景）。这些会让下游解析崩溃，比如 Axios 默认把响应当单层 JSON 处理，遇到多结果集直接丢第二张表。
性能影响：不加控制地让存储过程返回 10 万行 + 50 列，再经 Node.js pg 驱动转成 JS 对象，内存暴涨且 GC 延迟明显。
- SQL Server：在调用前加
SET NOCOUNT ON，避免额外消息干扰流式读取 - 统一用小写下划线命名列（如
user_name），在存储过程中用别名强制转换：SELECT name AS user_name FROM users - 多结果集场景（如先查主数据、再查统计），改用多个独立存储过程，或在应用层用
nextResult()（.NET）或resultSet.next()（Java JDBC）分批处理
权限与连接池配置常被忽略
给 API 服务用的数据库账号，如果只授予 EXECUTE 权限但没开 VIEW DEFINITION，某些驱动（如 Microsoft's mssql npm 包）在预编译阶段会查系统视图失败，报 Cannot find the object "sp_get_report" —— 实际过程存在，只是权限不足。
连接池配太小（如 max: 2）会导致高并发下请求排队，表现像 API 响应慢，排查时容易误判为存储过程性能问题。
- 最小权限原则：仅授予具体存储过程的
EXECUTE，禁用db_owner角色 - SQL Server 连接字符串加
encrypt=false（开发环境）或trustServerCertificate=true，否则 TLS 握手失败静默卡住 - PostgreSQL 的
pg池默认max: 10，但若每个请求都开新事务并长期 hold 连接，实际并发上限远低于此值
最麻烦的不是写不通，而是写通了但参数类型错一位、权限少一条、结果集没清空，导致问题隔几小时才复现一次。
