Ideas, releases, practical guides, and perspectives from the people building with MySQL.
在 MySQL-8.0 之前，DDL 是不能做到 Crash Safe 的。主要的问题有 3 个：
Server 层的 Metadata 和 InnoDB 的 Metadata/数据不一致。
Server 层的 Metadata 记录在文件中，例如表结构信息保存在 frm
文件中；InnoDB 中也有一份 Metadata 存储在表中。Crash 可能导致 Server 层的 Metadata
和 InnoDB 中的 Metadata、甚至表中的数据不一致。比如 Server 层存在表的
frm 文件，认为表存在，但是 InnoDB 的 ibd
数据文件已经不存在了，InnoDB 认为表不存在。
Binlog 和数据不一致。
比如 Crash 重启后，表已经存在了，但是 CREATE TABLE 却没有记录到
Binlog 中。
MySQL-8.0 为了实现 Atomic …
[获取更多]本文也有英文版：English version。
你有没有碰到过 mysqld 进程启动了很长时间也起不来的情况？这时候我们可以用 perf top
命令查看一下 MySQL 进程主要在干什么事情。如果你查看到的信息如下图所示，启动过程中 MySQL 的
主线程(mysqld_main函数开始的线程)
绝大多数的时间都花在了回滚事务上，那么很可能是遇到了大事务回滚。
这种情况最常见的一个场景是一个大事务在写 Binlog 时把磁盘空间占满了，导致了实例的宕机重启。我曾经遇到的最大的 Binlog
文件超过了 114GB。由于 Binlog Cache 的临时文件在写完 Binlog
后才被清理，所以这个事务总共占用了 228GB 的空间。MySQL 的参数
binlog_error_action …
本文也有英文版：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会严重的影响业务的性能。
根因分析
上图展示了两个事务的执行过程：
在 MySQL/PostgreSQL Buffer Pool 里面有一个 Pin 操作 — PostgreSQL 叫 Pin, MySQL InnoDB 叫 buf_block_fix / io_fix. 这些操作本质上都是把一个 page “pin” buffer pool 的某个位置上.
为什么在其他系统里很少见到这种代码? 答案是 PG 和 InnoDB 的 buffer pool 都用了同一种架构 — Slot-based Buffer Manager. 这种架构直接决定了 Pin 这个操作必须存在.
Slot-based Buffer Manager 结构
启动时, buffer pool 被切成 N 个固定大小的 slot (InnoDB 是 16KB, PG 是 8KB). slot 总数 N 在启动后不再变化.
数据结构上分三层:
以下信息是在测试一个 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引入了新的认证方式 …
本文也有英文版：English version。
内存泄漏、内存占用高是MySQL中较常见的问题，这些问题的排查非常依赖完善的内存监控信息。MySQL的Performance Schema中提供了内存的监控信息，PFS的内存统计信息粒度比较粗，很难精准的定位到问题代码。
上图是PFS中监控到的内存信息，虽然从内存监控中我们看到String::value和thd::main_mem_root上分配了很多的内存，但是这两个对象是MySQL中的基本对象，在非常多的地方使用。我们无法从这些信息推断出到底是什么操作导致了内存的占用。此外，由于PFS本身的内存占用比较高并且对性能有一定的影响，因此很多使用者不会在实例上开启PFS。
…
[获取更多]