本文也有英文版：English version。
MySQL官方从MySQL-5.6开始优化复制延迟问题，最先实现了 Schema 级别的 Binlog
并发应用。然而这个并发能力并不能解决日常的复制延迟。然后官方在
MySQL-5.7上实现了基于提交顺序的并发回放策略(Commit Order),
这种策略依赖主上的事务并发执行数量。主上并发执行的事务非常多的情况下，从库上回放的速度才会快。如果主上并发少，从库上回放速度仍然会变慢，产生复制延迟。因此官方又在
MySQL-5.7 上又实现了行级的并发策略(Writeset),
这种并发策略无论主上并发事务的多少，都能在从库上快速的并发回放。
我们很早以前就在线上全面使用了基于 writeset 的复制策略，writeset …
[获取更多]
MySQL 在执行 Online DDL 重建表的时候，可能会碰到 Duplicate
Entry 错误，从而导致 DDL 中途失败。失败信息如下所示：
1
2
mysql> alter table tt add c3 int, algorithm=inplace;
ERROR 1062 (23000): Duplicate entry '1' for key 'tt.uk_c2'
这是一个非常知名的问题，自从 MySQL-5.6 引入了 Online DDL 之后就一直存在。相关的Bug包括:
BUG#76895[5]最早报告了这个问题。BUG#76895 上提到的是 Duplicate
PRIMARY …
大事务是MySQL中一个痛点问题， 不仅会带来复制延迟，也会带来大量的稳定性问题。上一篇文章《MySQL大事务提交优化》介绍了大事务在提交时带来的问题，以及AliSQL中做的技术优化。这篇文章会介绍大事务在半同步复制时的问题，以及AliSQL中如何解决这个问题。
在《MySQL大事务提交优化》中，我们提到大事务提交时写Binlog会导致系统出现如下奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
本文也有英文版：English version。
在使用和运维MySQL的过程中你一定碰到过下面这种奇怪的慢SQL。
1.3s，并且慢SQL记录里也没有看到长时间的锁等待。
1.3s。
当这种情况出现时，最有可能的就是有大事务在提交。以下是一个模拟测试的结果，我们用Sysbench来模拟正常的业务，然后在后台每5秒执行一个大的UPDATE，可以看到大的UPDATE会严重的影响业务的性能。
根因分析
上图展示了两个事务的执行过程：
以下信息是在测试一个 SQL 时，AliSQL 的 Performance Agent 功能采集的 buffer pool 相关的监控信息。你能从这些监控信息看出是什么样的 SQL 在执行吗？
图中：bp = buffer pool, pg = page。
bp_pg_total 是 buffer pool 的总 page 数，一般不会变化的，除非修改了 buffer pool 的大小。
bp_pg_data 指的是 buffer pool 中数据文件的 page 的数量，包括 undo page。
bp_pg_dirty 指的是数据页中的脏页(被修改了，但还没有写入数据文件的页)的数量。
bp_pg_free 是 buffer pool 中空闲的 page 数量，这部分是没有被使用的部分。
bp_wait_free 当从存储上 读一个 page 到 buffer pool 时，如果没有空闲的 page 也没有净页(没有被修改的) …
密码认证的基本要素
基于密码的身份认证包括了两个部分：
基于密码的身份认证有一个原则：仅使用者知道密码。密码不能被存储在认证服务器中，在认证过程中也不能通过网络明文传输。因为存储的信息可能被窃取或者滥用，网络可能被监听。这些安全隐患都可能导致密码的泄露。
MySQL中常用的 mysql_native_password 和
caching_sha2_password 都遵循上述的要求。mysql_natvie_password
是MySQL-8.0之前最主要的认证方式。从MySQL-5.7.23开始，MySQL引入了新的认证方式 …
内存泄漏、内存占用高是MySQL中较常见的问题，这些问题的排查非常依赖完善的内存监控信息。MySQL的Performance Schema中提供了内存的监控信息，PFS的内存统计信息粒度比较粗，很难精准的定位到问题代码。
上图是PFS中监控到的内存信息，虽然从内存监控中我们看到String::value和thd::main_mem_root上分配了很多的内存，但是这两个对象是MySQL中的基本对象，在非常多的地方使用。我们无法从这些信息推断出到底是什么操作导致了内存的占用。此外，由于PFS本身的内存占用比较高并且对性能有一定的影响，因此很多使用者不会在实例上开启PFS。
…
[获取更多]Percona 论坛中经常出现的一个问题：Percona XtraDB Cluster (PXC) 中的每个节点都需要安装 XtraBackup 吗？ 这是一个合理的问题，尤其是在管理混合环境或试图最小化某些节点上的软件占用时。以下是实际机制和测试所确认的内容。
简短答案（但请继续阅读）
这取决于你希望该节点做什么。 这里的细微差别非常重要，因此值得详细说明 PXC 中 State Snapshot Transfer (SST) 的工作原理，以及 XtraBackup 在给定节点上的存在——或缺失——为什么重要。
PXC 中 SST 的快速复习
当一个新节点加入 Percona XtraDB Cluster，或者一个现有节点宕机时间过长以至于 Incremental State Transfer (IST) 不再可能时，集群会执行 State Snapshot Transfer (SST)。这本质上是捐献节点向加入节点的全量数据复制。
PXC …
[获取更多]This article was originally published in English at AnotherMySQLDBA.
本文详细介绍了 MySQL 8.0 的 JSON 函数的实际操作演练。JSON 支持从 MySQL 5.7 开始引入，但 8.0 增加了一组重要的改进——更好的索引策略、新函数以及多值索引——这些使得处理 JSON 数据变得更加实用。以下文档介绍了几个最常用的模式，包括 EXPLAIN 输出和值得了解的性能观察。
这不是一篇“JSON 与关系型”的辩论文章。如果你选择在 MySQL 中存储 JSON，你可能已经有自己的理由。此处的目标是确保你有效利用现有的工具。
环境
mysql> SELECT @@version, @@version_comment\G
*************************** 1. row ***************************
@@version: 8.0.36
@@version_comment: MySQL Community Server …MySQL分析：使用AI驱动的CLI工具
本文是 https://anothermysqldba.blogspot.com/2025/07/mysql-analysis-with-ai-powered-cli-tool.html 的中文翻译版。
作为MySQL DBA，我们经常在Linux终端窗口中工作。我们也喜欢可用的免费选项。这篇文章展示了一种方法，让我们可以在终端窗口中使用AI驱动的工具。你可以更新使用其他直接的AI提供商，但我将此示例设置为使用aimlapi.com，因为它免费提供有限使用的多个AI模型到你的终端，或者以很低的成本进行更多测试。
注：我不是AIMLAPI的付费发言人或任何其他身份 - 这只是一个简单的例子来突出这个想法。
问题
你正在查看一个有数百个表的遗留数据库，每个表都有复杂的关系和多年前做出的可疑设计决策。通常的过程包括：