SQL Server存储过程默认参数仅支持常量或NULL；MySQL不支持参数默认值，需在过程内手动赋值；PostgreSQL支持但显式传NULL不会触发默认值；跨库应避免依赖默认值，统一由上层处理。
SQL Server 存储过程怎么设默认参数
SQL Server 支持在存储过程中为参数指定默认值，但必须满足一个硬性条件：@param_name 的默认值只能是常量或 NULL，不能是函数（比如 GETDATE()）、表达式或变量。
常见错误现象是写成这样，然后执行报错：
CREATE PROCEDURE sp_get_orders
@start_date DATETIME = GETDATE() -- ❌ 错误：不允许函数作为默认值正确写法是显式在内部处理逻辑，而不是依赖默认值：
- 把参数设为
@start_date DATETIME = NULL - 在存储过程开头加判断：
IF @start_date IS NULL SET @start_date = GETDATE() - 后续所有业务逻辑统一用这个已赋值的
@start_date
MySQL 存储过程不支持参数默认值怎么办
MySQL 8.0 及以前版本的存储过程**完全不支持**在声明时写 DEFAULT 关键字给参数设默认值。这不是语法遗漏，是设计限制。
立即学习“前端免费学习笔记（深入）”；
使用场景里如果前端调用方希望“不传参就走默认行为”，就得换思路：
- 所有输入参数都声明为
IN类型且允许NULL - 在过程体开头批量检查：
IF p_limit IS NULL THEN SET p_limit = 20; - 避免用
COALESCE(p_limit, 20)在 WHERE 中直接替换——可能干扰索引下推
注意：MySQL 的 DEFAULT 关键字只在函数（CREATE FUNCTION）中可用，存储过程里写了就语法报错。
PostgreSQL 函数如何安全设默认值并兼容 NULL
PostgreSQL 的 CREATE FUNCTION 支持真正的默认值，但有个关键细节：如果调用时不传参，会把默认值代入；但如果显式传了 NULL，它就是 NULL，不会被默认值覆盖。
这导致一个典型坑：前端 JavaScript 发送 null，后端转成 SQL 的 NULL，结果触发了和预期不符的分支逻辑。
- 推荐写法是统一用
IS NULL判断，而非依赖默认值兜底 - 例如：
my_date TIMESTAMP WITH TIME ZONE DEFAULT NOW()，但调用仍建议写IF $1 IS NULL THEN ... END IF; - 参数类型要和默认值严格匹配，
TEXT DEFAULT 'abc'和TEXT DEFAULT ''在 collation 行为上可能有差异
跨数据库兼容写法：为什么别依赖存储过程默认值
想写一次存储过程、多库复用？默认值是最先撞墙的地方。SQL Server、MySQL、PostgreSQL 对它的支持程度、语义、甚至关键字都不同。
性能影响倒不大，但维护成本高：
- SQL Server 允许
= '2024-01-01'，MySQL 必须手动赋值，PostgreSQL 允许但含义不同 - ORM（如 Dapper、MyBatis）调用时，对未传参的处理策略不一致，有的发空值，有的跳过参数
- 测试用例容易漏掉「显式传 NULL」这个边界情况，线上才暴露逻辑偏差
真正省事的做法是：存储过程只做数据操作，参数合法性、默认逻辑、空值归一化全交给上层应用或视图封装。存储过程本身保持“参数即事实”，不猜意图。
