mysql event不支持传参，因其create event语法要求do后仅接固定语句，禁止运行时参数；需通过无参存储过程封装逻辑或改用系统级定时任务实现参数化调度。
不能直接在 Navicat Premium 16 里给事件（EVENT）传参，MySQL 的 EVENT 语法本身不支持参数绑定，所谓“带参数的定时执行”，必须靠包装层绕过这个限制。
为什么 EVENT 无法接收参数
MySQL 的 CREATE EVENT 语句只允许固定调度逻辑，DO 后面只能跟一条可执行语句（比如 CALL proc_name()），不接受变量、表达式或运行时参数。即使你写成 CALL my_proc(NOW(), 'auto')，也会在创建时就报错 —— 因为 NOW() 是函数调用，不是常量值，而 EVENT 要求所有参数在定义时刻就能确定。
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，往往卡在 CALL 后面带括号参数的位置。
- MySQL 官方文档明确说明：
EVENT不支持动态参数传递 - Navicat 的图形化「新建事件」界面，底层仍是生成标准
CREATE EVENT语句，没有额外扩展能力 - 试图在
EVENT中用SET @var = ...再传给存储过程，也无效 ——EVENT执行上下文不共享用户变量
可行方案：用无参存储过程封装参数逻辑
核心思路是把“参数”固化进存储过程内部，或者通过查表/读配置方式间接获取。这样 EVENT 只需调用一个无参入口，由它自己决定该用什么值。
- 若参数相对稳定（如固定业务类型、环境标识），直接硬编码进存储过程体，例如：
SET p_env = 'prod'; - 若参数需动态变化（如每次执行要取最新配置），建一张控制表
event_config，字段包括key、value、updated_at，在存储过程中用SELECT value INTO v_param FROM event_config WHERE key = 'batch_size'; - 若需区分执行批次（如按日期分区处理），用
DATE(NOW())或YEARWEEK(NOW())这类确定性函数生成逻辑参数，避免依赖外部输入 - 不要在封装过程里做复杂计算或远程调用，否则
EVENT执行超时（默认 60 秒）会导致中断且无重试
Navicat 中创建和调试的关键操作点
在 Navicat Premium 16 里完成这套流程，要注意几个容易被忽略的实操细节：
- 创建存储过程时，右键数据库 →「函数」→「新建函数」→ 类型选「PROCEDURE」，名称别带空格或特殊字符（如
daily_cleanup_v2可以，daily cleanup会报错） - 写完存储过程后，务必先手动执行一次：
CALL daily_cleanup_v2();，确认无语法错误、权限足够、逻辑符合预期 ——EVENT不会告诉你哪一行错了，只会静默失败 - 新建事件时，Navicat 图形界面中「计划」页签里的「开始时间」必须是过去或当前时间，否则事件不会触发（MySQL 要求
STARTS时间 ≤ 当前时间才进入激活状态） - 启用事件后，用
SHOW EVENTS;查看状态列是否为ENABLED，并检查Last_executed是否随时间更新；如果一直是NULL，大概率是存储过程执行出错被跳过 - 调试日志只能靠在存储过程中加
INSERT INTO debug_log VALUES (NOW(), 'step1');，MySQL 自身不提供EVENT级别的执行日志
替代方案：用系统级定时任务触发带参调用
如果业务确实需要每次传不同参数（比如从命令行读取时间范围），就彻底放弃 EVENT，改用操作系统定时任务 + mysql 命令行客户端。
- Windows 下用任务计划程序，触发命令类似：
"C:\Program Files\MySQL\MySQL Server 8.0\bin\mysql.exe" -uuser -ppass -e "CALL my_proc('2026-09-07', 'full');" - Linux 下用
crontab，配合date +\%Y-\%m-\%d动态拼接参数，比 MySQL 内置事件灵活得多 - 这种方案绕过了 Navicat，但能真正实现参数化调度；缺点是需要维护额外脚本和权限配置，且不在数据库内统一管理
- 注意密码明文风险：建议用
~/.my.cnf配置文件存认证信息，并设chmod 600，别裸写在命令里
最复杂的部分不是写存储过程，而是让它的每次执行都可观察、可追溯、可干预。MySQL 的 EVENT 天然缺乏反馈通道，一旦封装过深，出问题时连日志都难定位。
