qq_38140936的博客

最近有好几个朋友问，如何将 performance_schema.events_statements_xxx 中的 TIMER 字段（主要是TIMER_START和TIMER_END）转换为日期时间。因为 TIMER 字段的单位是皮秒（picosecond），所以很多童鞋会尝试直接转换，但转换后的结果并不对，看下面这个示例。下面会从源码角度分析 TIMER 字段的生成逻辑。对源码分析不感兴趣的童鞋，可直接跳到后面的案例部分看结论。

1. mysql.user 中的 authentication_string 字段存储的是。2. 服务端对客户端进行身份验证的流程图如下：服务端在对客户端进行身份验证时，会首先发送一个 20 字节的盐值，客户端接受到这个盐值后，会返回一个通过以下公式计算的加密密码。

综合上面的分析，异步删除各参数的作用如下，注意，这几个参数的默认值都是 no。另外，在通过POPTRIM之类的命令从列表（List），集合（Set），有序集合（Sorted Set）中弹出或者移除元素时，对于这些元素的删除都是同步的，并不会异步删除。如果元素的值过大（最大值由 proto-max-bulk-len 决定，默认是 512MB），依然会阻塞主线程。

综合上面的分析，主从延迟的常见原因及解决方法如下图所示。

基于 RDB 文件进行解析，常用工具是 redis-rdb-tools（https://github.com/sripathikrishnan/redis-rdb-tools）。不过这个工具已近 5 年未更新，不支持 Redis 7，而且由于使用 Python 开发，解析速度较慢。目前较为活跃的替代工具是 https://github.com/HDT3213/rdb ，该工具支持 Redis 7，并使用 Go 开发。本文要介绍的工具（）也是一个在线分析工具，其实现思路与类似，但功能更为强大实用。

在中显示的每个阶段的耗时，实际上是由下一个阶段的采集时间减去当前阶段的采集时间得出的。每个阶段的采集时间是通过在代码的不同路径中植入实现的，采集的是系统当前时间。这种实现方式在判断操作当前状态（通过 SHOW PROCESSLIST）和分析各个阶段耗时（通过 SHOW PROFILE ）时存在一定的误导性，主要是因为预定义的阶段数量是有限的。在 MySQL 8.4 中，共定义了 98 个阶段，具体的阶段名可在mysqld.cc中的数组找到。在表空间导入操作中，虽然大部分耗时显示为。

在 MySQL 的日常管理过程中，大家或多或少会遇到权限认证相关的问题。例如，本来能够正常执行的操作，可能在新增一个账号或授权后就突然失败了。这种现象往往让人误以为是 bug，但很多时候，其实并不是。

是一个静态变量，其类型为，其中是_Atomic类型的别名。_Atomic是 C11 标准引入的关键字，用于声明原子类型，保证在多线程环境中对该类型的操作是原子的，避免数据竞争。其中，是在分配内存时调用，它通过原子操作让 used_memory 加__n。而则是在释放内存时调用，它通过原子操作让 used_memory 减__n。这两个宏确保了在内存分配和释放过程中的准确更新，并且避免了并发操作带来的数据竞争问题。

最近碰到一个 case，值得分享一下。现象就是一个 update 操作，在 mysql 客户端中执行提示 warning，但在 java 程序中执行却又报错。

在 MySQL 中，如果我们想查看实例当前正在执行的 SQL，常用的命令是。但如果 SQL 过长的话，就会被截断。这时，我们一般会用来查看完整的 SQL。最近碰到一个 case，发现无论是使用，还是 performance_schema.processlist 都无法获取完整的 SQL，反倒 information_schema.processlist 可以。最后发现，无法查看完整的 SQL 竟然与 performance_schema_show_processlist 参数有关。

MGR 选择 Donor 是随机的。MGR 在执行克隆操作之前，会将 clone_valid_donor_list 设置为 Donor 的 endpoint，所以，在启动组复制之前，在 mysql 客户端中显式设置 clone_valid_donor_list 是没有效果的。MGR 执行克隆操作，实际上调用的就是命令。

最近碰到一个 case，一台主机上，部署了多个实例。之前使用的是 MySQL 8.0，启动时没有任何问题。但升级到 MySQL 8.4 后，部分实例在启动时出现了以下错误。下面我们来分析下这个报错的具体原因及解决方法。

结合代码和上面四个案例的分析，最后我们总结下 MGR 的新主选举算法：1. 如果集群中存在 MySQL 5.7 的节点，则会将 MySQL 5.7 的节点作为候选节点。如果最小版本小于 MySQL 8.0.17，则所有的节点都可作为候选节点。如果最小版本大于等于 MySQL 8.0.17，则只有最小版本的节点会作为候选节点。3. 在候选节点的基础上，会进一步根据候选节点的权重和 server_uuid 选择 Primary 节点。具体来说，

Druid 连接池在以下四种场景下会检测连接的有效性：申请连接、归还连接、创建新物理连接以及定期检测。Druid 通过开启 keepAlive 参数，定期对空闲连接进行有效性检测，确保连接保持活跃状态。当连接的空闲时间超过 keepAliveBetweenTimeMillis 时，Druid 会触发 Keep-Alive 检测，验证连接的有效性。如果连接有效，则重新放回连接池；如果无效，则将其销毁。