MySQL主从复制中Event默认被复制，导致主从并发执行引发数据重复等问题；推荐在从库配置event_scheduler=OFF并设binlog_format=ROW，或主库创建Event时加NOT ON SLAVE子句来阻止从库执行。
MySQL主从复制中Event默认会同步到从库执行
MySQL的EVENT默认是**被复制**的（只要binlog_format支持，且未显式禁用）。这意味着你在主库创建一个每秒执行一次的EVENT，它会被写入binlog、传到从库、并在从库上也启动执行——结果就是同一个逻辑在两个节点上并行跑，造成数据重复、资源争抢甚至主键冲突。
关闭Event在从库的自动执行（推荐）
最稳妥的做法不是删Event，而是让从库“知道这是主库创建的，我不该自己跑”。关键参数是：event_scheduler + skip-slave-start组合，但真正起效的是：
-
SET GLOBAL event_scheduler = OFF—— 在从库上手动关掉调度器（重启后失效） - 更持久的方式：在从库的
my.cnf中添加event_scheduler = OFF，然后重启mysqld - 注意：
event_scheduler = OFF只影响本地调度行为，不影响binlog中已有的EVENT语句被重放；所以必须配合下一步
真正阻止EVENT被从库执行的核心，是让从库**跳过EVENT相关的DDL事件**。这需要设置：
-
SET GLOBAL binlog_format = ROW（如果尚未启用）—— 因为STATEMENT格式下，CREATE EVENT语句会被原样重放；而ROW格式不记录DDL，EVENT本身不会进入binlog - 但注意：
ROW模式下，EVENT的触发动作（比如INSERT）仍会以行事件形式记录，所以EVENT本身不复制 ≠ 它引发的数据变更不复制
主库创建Event时显式指定NOT SLAVE
MySQL 5.7.2+ 支持在CREATE EVENT语法中加ON SLAVE或NOT ON SLAVE子句。虽然文档里写得模糊，但实测有效的是：
CREATE EVENT e_daily_cleanup
ON SCHEDULE EVERY 1 DAY
DO
DELETE FROM logs WHERE created_at < NOW() - INTERVAL 30 DAY;
→ 这个EVENT会在主从都存在，但你可以在从库上手动禁用：
-
ALTER EVENT e_daily_cleanup DISABLE—— 立即停用，且重启后仍保持DISABLE状态 - 或者直接
DROP EVENT e_daily_cleanup（前提是确认从库不需要该逻辑）
⚠️ 注意：DISABLE操作本身**不会被复制**（它是DDL，但不写binlog），所以必须在每个从库上单独执行。
双主或多节点PXC集群中Event更危险
在Percona XtraDB Cluster（PXC）里，EVENT行为更特殊：它只在创建它的那个节点上运行，其他节点上状态是SLAVESIDE_DISABLED。但如果你误在多个节点都创建了同名EVENT，或者用STATEMENT格式复制过去，就可能触发多点并发执行。
验证方式很简单：
- 查
SELECT event_name, status FROM information_schema.EVENTS WHERE event_schema = 'your_db'; - 在PXC中，非创建节点上看到
status = 'SLAVESIDE_DISABLED'才是正常；如果是'ENABLED'，说明已被复制并激活
这种场景下，靠event_scheduler = OFF不够，必须统一规范：所有定时任务只部署在**单个指定节点**，其余节点严格禁止创建或启用任何EVENT。
真正容易被忽略的点是：即使你设了binlog_format = ROW，如果主库上先用STATEMENT建了EVENT，再切ROW，旧EVENT仍存在于从库且可能被启用；清理必须手动介入，不能依赖格式切换自动解决。
