init_connect 无法审计 select 查询，仅在连接建立时触发一次，适合登录审计；审计特定表的 select 需用 binlog（row 格式）+ thread_id 关联、general_log、代理层（如 proxysql）、mysql 8.0+ audit_log 插件或应用层埋点。
init_connect 本身无法审计 SELECT 查询行为，它只在用户连接建立后、执行第一条语句前触发一次，仅适合记录登录事件。想审计「特定表的 SELECT」，必须结合 binlog（且需 ROW 格式）或使用 MySQL 企业版审计插件 / 社区版替代方案（如 mysql-audit 插件或代理层拦截）。用 init_connect + 脚本“模拟审计 SELECT”属于常见误解，实际会漏掉 99% 的查询。
为什么 init_connect 不能捕获 SELECT 操作
init_connect 的执行时机非常明确：仅在新连接建立后、用户发出第一条 SQL 前执行一次。它不监听后续任何语句，也不感知 SELECT、UPDATE 等类型。
- 用户登录后执行
SELECT * FROM users;→init_connect不响应 - 同一连接中反复执行 100 次
SELECT→ 只有第一次连接时插入一条日志 - 错误认知：“把 SELECT 逻辑写进 init_connect 就能审计” → 实际语法都不合法，MySQL 会直接拒绝执行
真正可行的 SELECT 审计路径：binlog + thread_id 关联
前提是已启用 binlog 且格式为 ROW（STATEMENT 或 MIXED 无法还原具体表名和条件），再通过 init_connect 记录的 thread_id 与 binlog 中的 thread_id 字段对齐，才能定位某次 SELECT 的发起者。
-
binlog_format = ROW是硬性要求；MIXED在 SELECT 场景下多数不写入 binlog - MySQL 5.7+ 的 binlog event 中，
Rows_query_log_events（需开启binlog_rows_query_log_events=ON）可记录原始 SQL，但仅限于 DML，SELECT仍不会进入 binlog —— 这是关键限制 - 所以严格来说：原生 MySQL 社区版不记录 SELECT 到 binlog，无论怎么配
init_connect都无法补救
绕过限制的实操方案：用 general_log 或代理层
如果必须审计 SELECT（尤其是特定表），放弃 init_connect，改用以下任一方式：
- 开启
general_log = ON，并设置general_log_file = '/var/lib/mysql/general.log'；缺点是日志爆炸、性能损严重，且需自行 grep 过滤SELECT.*users类模式 - 部署
ProxySQL或MySQL Router，在代理层解析 SQL 并匹配SELECT.*FROM.*`orders`正则，写入外部审计系统 - 升级到 MySQL 8.0+ 并启用官方
audit_log插件（需企业版授权）或社区兼容插件如mysql-audit（McAfee 开源，支持 SELECT 过滤） - 应用层埋点：所有 SELECT 必须走封装函数（如
db.query("SELECT ... FROM orders")），由 SDK 统一打审计日志
init_connect 脚本唯一可靠用途：登录审计 + 连接上下文注入
别强求它做超出设计的事。它真正稳定可用的场景只有两个：
- 记录谁、什么时间、从哪台 IP 连上了数据库（
connection_id(),user(),current_user()） - 为每个连接自动执行环境设置，例如：
SET NAMES utf8mb4; SET sql_mode='STRICT_TRANS_TABLES';
试图用它“配合脚本”去解析后续 SELECT，本质是在日志文件里盲搜字符串，既不可靠（无事务上下文）、也难关联（没线程级会话 ID 绑定），还容易被注释、换行、多语句干扰。真要落地审计，优先砍掉这个思路。
