MySQL存储过程不支持默认参数，所有IN参数调用时必须显式传值，否则报错；可通过传NULL并配合IS NULL判断模拟可选参数，或拆分过程、动态SQL、应用层组装等替代方案。
MySQL存储过程不支持真正的可选参数（即没有默认值、不强制传参的参数）。所有 IN 参数在调用时都必须显式提供值，否则会报错 ERROR 1318 (42000): Incorrect number of arguments for PROCEDURE xxx; expected Y, got Z。
为什么不能像函数那样设 DEFAULT？
MySQL 存储过程语法中，CREATE PROCEDURE 不允许为 IN 参数指定默认值（如 IN param INT DEFAULT 0 是非法的）。这是与 PostgreSQL 或 SQL Server 的关键差异，也是最容易踩坑的地方。
常见错误现象：
- 写
IN name VARCHAR(50) DEFAULT 'guest'→ 直接语法报错 - 调用时少传一个
IN参数 → 报Incorrect number of arguments - 试图用
IF param IS NULL THEN ...判断“是否传了” → 实际上只要传了NULL，它就是NULL，不是“未传”
替代方案：用 NULL 做语义上的“可选”
虽然不能跳过参数，但可以约定：调用者传 NULL 表示“该参数不生效”，然后在过程体内做条件判断。这是最常用、兼容性最好的做法。
实操建议：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 把需要“可选”的参数声明为
IN，类型允许NULL（例如VARCHAR(100)本身可空，INT也支持NULL） - 在
BEGIN后立刻用IF param_name IS NULL THEN跳过相关逻辑 - 避免在 WHERE 中直接写
col = param—— 这会漏掉param IS NULL的情况；改用(param IS NULL OR col = param) - 如果涉及多个可选条件，优先用
AND拼接，而不是动态拼 SQL（后者易引发注入且难调试）
示例：
DELIMITER $$
CREATE PROCEDURE search_user(
IN p_name VARCHAR(50),
IN p_age INT,
IN p_dept_id INT
)
BEGIN
SELECT id, name, age, dept_id FROM users
WHERE (p_name IS NULL OR name LIKE CONCAT('%', p_name, '%'))
AND (p_age IS NULL OR age = p_age)
AND (p_dept_id IS NULL OR dept_id = p_dept_id);
END$$
DELIMITER ;
调用方式：
-
CALL search_user('张', NULL, 101);→ 按姓名模糊+部门精确查 -
CALL search_user(NULL, 25, NULL);→ 只按年龄查
更灵活的方案：拆成多个存储过程或用动态 SQL
当“可选参数”组合太多（比如 5 个参数，有 32 种有效组合），硬写 IS NULL 判断会让 WHERE 条件臃肿、执行计划变差。这时可考虑：
- 拆成 3–4 个语义清晰的小过程（如
search_by_name、search_by_dept、search_by_name_and_dept），比一个大而全的过程更易维护 - 用
CONCAT+PREPARE/EXECUTE拼接 SQL（注意：必须严格校验输入，防止 SQL 注入；且PREPARE在存储过程中无法缓存，性能不如静态 SQL） - 把复杂筛选逻辑交给应用层组装 WHERE 条件，数据库只提供基础查询接口 —— 很多团队最终选择这条路
真正容易被忽略的是：MySQL 存储过程的参数数量是编译期固定的，所谓“可选”全是靠 NULL 协议模拟出来的。别指望它像 Python 函数那样支持 *args 或命名参数调用 —— 每次 CALL 都必须严格对齐参数个数和顺序。
