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」这个边界情况，线上才暴露逻辑偏差

真正省事的做法是：存储过程只做数据操作，参数合法性、默认逻辑、空值归一化全交给上层应用或视图封装。存储过程本身保持“参数即事实”，不猜意图。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！