用 connection_id() 和 user() 可查当前连接id和真实登录账号（含ip），如 'app_user@10.20.30.40'；current_user() 返回权限系统认定的授权主体（如 'app_user'@'%'），二者语义不同，不可混用。
怎么查当前连接的 ID 和用户？
直接用 CONNECTION_ID() 和 USER() 就行，这两个函数返回的是当前会话的连接标识和完整用户字符串（含主机名），不是登录用户名。比如执行 SELECT CONNECTION_ID(), USER();，结果可能是 12345 和 'app_user@10.20.30.40'。
常见错误是误用 CURRENT_USER() —— 它返回的是权限系统认定的授权主体（比如 'app_user'@'%' ），不反映实际连接来源；而 USER() 才是你真正连进来时填的那个账号+IP。
-
CONNECTION_ID()是整数，可直接参与比较或记录日志 -
USER()返回格式固定为'user@host'，解析需自己切分，别指望 MySQL 帮你拆 - 在存储过程或触发器里调用，返回值仍是当前会话的，不是定义者会话
为什么 PROCESSLIST 里看到的 ID 和 CONNECTION_ID() 一致？
因为它们本来就是同一个东西：SHOW PROCESSLIST 第一列的 Id 字段，就是每个线程的 CONNECTION_ID() 值。这说明这个 ID 是 MySQL server 层分配的唯一会话标识，不是客户端生成的。
注意点：如果开了线程池（如 MySQL 8.0 的 thread_pool 插件），CONNECTION_ID() 仍有效，但底层线程可能复用，ID 不代表 OS 线程号。
- 想查自己这条连接在
PROCESSLIST中的位置？直接SELECT * FROM information_schema.PROCESSLIST WHERE ID = CONNECTION_ID(); -
information_schema.PROCESSLIST需要PROCESS权限，普通只读账号可能查不到其他人的行 - 某些云数据库（如阿里云 RDS）会隐藏部分字段（如
INFO列为空），但ID和USER通常可见
USER() 和 CURRENT_USER() 混用导致权限判断出错
这是线上最容易踩的坑：用 USER() 做权限白名单校验，结果发现测试通过、上线就失败。因为 USER() 返回的是「你怎么连进来的」，而权限检查走的是 CURRENT_USER() —— 即「MySQL 认为你该是谁」。
例如：你用 root@'192.168.%' 连入，但服务器上只建了 root@'%' 这个账号，那么 CURRENT_USER() 是 'root'@'%'，而 USER() 是 'root'@'192.168.1.100'。两者 host 段不等价。
- 做连接级审计日志时，优先记
USER()，它反映真实接入点 - 写存储过程判断“是否管理员”时，应该比对
CURRENT_USER()是否匹配授权账号模式 - 不要在 SQL 中拼接
USER()结果去动态构造库名或表名，容易被注入；它的内容不可信
这些函数在连接断开后还有效吗？
无效。只要连接关闭，CONNECTION_ID() 对应的会话就从 server 内存中清除了，再查也没意义。而且函数本身必须在活跃会话中执行 —— 比如你在连接已断的客户端里执行，会直接报错 MySQL server has gone away。
另外，这些函数不走查询缓存，也不受事务隔离级别影响，每次调用都是实时取值。
- 想持久化记录某次连接的行为？必须在连接存活期间把
CONNECTION_ID()和USER()存到业务表里 - 不要在 long-poll 或 keep-alive 场景中缓存
CONNECTION_ID()值当作全局 ID 用，连接重连后 ID 会变 - 有些 ORM（如 SQLAlchemy）会在连接池中复用物理连接，但每次
get_connection()拿到的逻辑连接，其CONNECTION_ID()是新的
实际用的时候，最常漏掉的是 host 段差异和权限上下文切换——函数看着简单，但值的语义得盯紧到底是“谁连的”还是“谁被认的”。
