MySQL本身不支持双人授权语义，但可通过角色+存储过程封装审批动作实现：申请人调用sp_submit_ddl插入待审记录，审批人调用sp_sign_approval签名确认，最终由sp_execute_pending校验状态后执行，确保“谁批准、谁执行”全程留痕且不可绕过。
MySQL 本身不支持“双人授权”语义（如一条 INSERT 必须由 A 提交、B 签字才生效），但可以通过账号分工 + 外部流程控制，把“谁执行了什么”和“谁批准了什么”在数据库层面强制解耦并留痕。核心不是改 MySQL 功能，而是让每个动作都绑定不可绕过的身份与时间戳。
init_connect 只记录登录，不满足双人审计要求
很多人一上来就配 init_connect 插入登录日志，但这只能回答“谁连上了”，无法回答“谁批准了这次 DDL”或“谁确认过这条 DELETE 的业务合理性”。它缺失审批上下文，且对 root 或高权限账号无效（init_connect 不对拥有 SUPER 权限的用户触发）。如果你只靠这个，等于把“门禁打卡”当成“放行审批”。
-
init_connect对root@localhost默认不生效，除非显式移除SUPER权限（不推荐） - 它不记录 SQL 内容、不关联审批编号、无法区分“开发连库查数据”和“运维执行上线脚本”
- 所有写入都发生在连接建立时，后续操作完全脱钩
用角色+存储过程封装审批动作，强制调用链
真正能落地双人制的地方，在于把“需审批的操作”全部收口为带签名验证的存储过程。例如，上线一张新表必须调用 sp_approve_create_table，而不是直接 CREATE TABLE。该过程内部检查：申请人是否在白名单、审批人是否已用私钥签名、审批时效是否在 15 分钟内、目标库名是否匹配预设策略。
- 创建专用角色：
role_requestor（只能调用sp_submit_ddl）、role_approver（只能调用sp_sign_approval和sp_execute_pending） -
sp_submit_ddl插入待审记录到audit_pending表，含requester、sql_text、sha256、expires_at -
sp_sign_approval要求传入pending_id和approver_signature（可基于 HSM 或简单 HMAC 实现），成功后更新状态并写入audit_approval - 最终执行必须通过
sp_execute_pending—— 它只允许status = 'approved'且未过期的记录，并以 DEFINER 身份执行原始 SQL
/etc/sudoers.d/ + 触发器不是数据库方案，慎用
有团队把 MySQL 审批做成 Linux 层 sudo 流程（如 sudo mysql-approve --id 123），这看似双人，实则把数据库审计降级为系统日志审计。问题在于：mysql-approve 执行的是本地命令，不是数据库事务；它无法约束远程客户端直连执行；也无法保证 SQL 在执行时仍与审批时完全一致（比如参数化查询中变量被篡改）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- MySQL 层面无法感知该 sudo 命令，
information_schema.PROCESSLIST里看不到审批上下文 - 如果审批脚本直接拼接字符串执行 SQL，存在二次注入风险（原始 SQL 已签名，但执行时被重写）
- 审计表里只会记下
root@localhost执行了一条语句，丢失申请人、审批人、原始哈希等关键字段
audit_log 插件 + 外部解析是唯一开箱即用的强审计路径
MySQL 5.7+ 官方 audit_log 插件（企业版）或 MariaDB 的 server_audit 是目前最接近“双人审计”效果的原生方案：它记录完整连接信息（user、host、command、query、timestamp），且日志不可删改（写入文件或 socket）。但它仍不自带审批逻辑，必须靠外部服务补全。
- 开启后，所有 SQL 都进
/var/log/mysql/audit.log（JSON 格式），包括谁、何时、在哪台客户端、执行了什么 - 用 Python 脚本监听该文件，当检测到高危操作（如
DROP TABLE、TRUNCATE），自动提取user和query，生成审批请求推送到企业微信/钉钉 - 审批人点击通过后，脚本向 MySQL 发送一条带唯一
approval_id的 INSERT 到audit_approval表，再调用sp_execute_pending执行原始 SQL - 关键点：所有高危操作的执行，必须依赖
audit_approval表中对应记录存在且状态为'granted'，否则存储过程拒绝执行
真正的难点不在怎么记日志，而在于如何让“审批完成”这件事，在数据库内成为 SQL 执行的必要前置条件。任何绕过这个检查的动作，都会导致审计链条断裂——哪怕只漏掉一次 GRANT 操作，整个双人机制就形同虚设。
