风控系统对 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成功” 就算完事。
