mysql风控部署必须启用row格式+gtid+binlog，配置cdc_reader账号及连接池参数，并验证binlog可读性，否则规则引擎无法稳定消费变更。
风控系统对 MySQL 的要求不是“能用就行”，而是要满足高可用写入、低延迟查询、规则引擎实时读取 binlog 等硬性条件；直接用默认配置或一键安装包部署，上线后大概率会卡在 binlog_format=STATEMENT 不兼容、max_connections 突然耗尽、或规则引擎连不上主库的 GTID 位置上。
MySQL 必须启用 row 格式 + GTID + 开启 binlog
实时规则引擎（如 Flink CDC、Canal、Maxwell）依赖 MySQL 的变更日志做流式规则匹配，STATEMENT 或 MIXED 格式会导致解析失败或数据不一致；GTID 是跨节点定位位点、故障后自动续接的必要前提。
-
binlog_format=ROW（必须，不能是 STATEMENT） -
gtid_mode=ON且enforce_gtid_consistency=ON -
log_bin=/var/lib/mysql/mysql-bin（路径需有写权限，且不在 tmpfs 上） - 重启前确认
skip_slave_start=OFF，否则从库启动时不会自动拉取 binlog
风控库表结构要预留 rule_engine 兼容字段
规则引擎常需按事件时间窗口聚合、按用户 ID 分桶、或补全缺失字段；若业务表没设计好，后续加字段或改类型会锁表，影响实时风控拦截。
- 每张核心事实表必须含
event_time（DATETIME(3)或TIMESTAMP(3)，精度到毫秒） - 主键建议用
BIGINT UNSIGNED自增或BINARY(16)（UUIDv4 压缩后），避免规则引擎分片时 hash 倾斜 - 避免
TEXT/JSON存关键判断字段（如risk_level、rule_hit_list），规则引擎通常不支持 JSON 内部索引 - 建表时显式指定
ENGINE=InnoDB和ROW_FORMAT=DYNAMIC，防止某些版本默认用 COMPACT 导致大字段截断
连接池与权限要按角色隔离，不能共用 root
规则引擎、风控服务、离线计算任务对数据库的访问模式完全不同：引擎要长连接监听 binlog，服务要短连接高频查最新状态，离线任务则可能扫全表；混用账号会导致连接打满、慢查询拖垮主库。
- 为规则引擎单独建账号：
CREATE USER 'cdc_reader'@'%' IDENTIFIED BY 'xxx';，只赋予SELECT, REPLICATION SLAVE, REPLICATION CLIENT - 风控服务账号禁用
FILE、PROCESS、SUPER权限，且限制max_user_connections=200 - 连接池（如 HikariCP）中设置
connection-timeout=3000、idle-timeout=600000、max-lifetime=1800000，避免空闲连接被 MySQL 的wait_timeout（默认 28800 秒）误杀 - 所有客户端连接串必须带
?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai，否则 Java 8u251+ 会因时区或密钥问题拒绝连接
验证 binlog 可读性比“能连上”更重要
很多团队卡在“规则引擎一直提示 No binlog position found”，其实不是配置错，而是没真正验证 binlog 是否可被消费。
- 用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001查看输出里是否有### UPDATE ...行，没有说明ROW格式未生效 - 执行
SHOW MASTER STATUS;，记录File和Position，再用规则引擎客户端（如 canal-admin）手动填入该位点启动，观察是否能收到第一条变更 - 如果引擎报
Could not find first log file name in binary log index file，检查log_bin_index路径是否和log_bin同目录，且 MySQL 进程对该文件有读权限
真正难的不是装 MySQL，而是让规则引擎第一次稳定拉到那条 INSERT INTO risk_event VALUES (..., '2024-06-12 10:30:45.123', ...) —— 所有配置都得围绕这个动作闭环验证，而不是停留在 “systemctl start mysqld 成功” 就算完事。
