MySQL 8.0 DDL 是一个复杂的过程，涉及比较多的模块，例如：MDL 锁，表定义缓存，行格式，Row Log，DDL Log，online 属性，表空间物理文件操作等。本文主要通过与5.7版本的对比讲述原子性相关的实现。

InnoDB 是 MySQL 默认的存储引擎，而提到InnoDB的内存，就绕不开Buffer Pool，该结构对性能的影响重大。但事实上InnoDB的内存消耗并不只有BP而已，其内部还有许多重要的结构（如AHI、Change Buffer、Log buffer等）也占据着不可忽视的内存空间。了解InnoDB的内存结构和使用特点对于MySQL运行期间的内存选型和使用有很大帮助。

在 InnoDB 引擎下，运行同一行内容在不同事务之间读写互不干扰，这是我们经常会碰到的业务场景，它也被认为是理所当然的。而这一特性的实现其实会比描述起来复杂得多。

MVCC 就是允许在特定隔离级别的 InnoDB 引擎下，对事务执行一致的读操作。避免了并发事务下对一般类型查询的锁竞争，也是一种增强并发事务读写能力的功能。

就像一位称职的摄像师，在你每个人生的高光点都会按下快门记录当下与之前的影像。

它本质上就是一个链表，每一行内容的版本都指向上一个版本，其中除了数据本身，还包含了事务可见性的信息在内，这些可见性信息用于判断哪个版本才能对当前的查询可见。

对于MYSQL的INNODB存储引擎的索引，大家是不陌生的，都能想到是 B+树结构，可以加速SQL查询。但对于B+树索引，它到底“长”得什么样子，它具体如何由一个个字节构成的，这些的基础知识鲜有人深究。本篇文章从MYSQL行记录开始说起，层层递进，包括数据页，B+树聚簇索引，B+树二级索引，最后在文章末尾给出MYSQL索引的建议。

本短文大致介绍了一下mysql的wal机制，一些内部结构和算法，锁和状态机的视角，以及程序员经常碰到的“删除”。

近日订单履约系统发生了一起故障，导致下发的订单积压。究其原因是慢查询导致的，现在痛定思痛看看为什么发生了慢查询。

介绍索引的数据结构、查找算法、常见的索引概念和索引失效场景。

腾讯机器学习平台太极后端数据库是自己运维的Mysql，历史原因没有用公司CDB、TDSQL等，之后还是要进行数据库迁移把db维护交给专业的人去运维，这块太极平台没有专门的dba运维出现了不少问题，如Mysql主节点硬盘故障，备机切主导致系统中断半小时；后端接口调用不合理导致循环调用数据库致使数据库cpu持续维持在高位以及前端接口数据返回缓慢等问题。这块Mysql优化就需要开发自己去多了解Mysql系统架构、性能调优相关问题，监控Mysql 机器运行状态，本文就简单介绍下Mysql系统分析思路和采用的工具。

Mysql 作为互联网中非常热门的数据库，其底层的存储引擎和数据检索引擎的设计非常重要，尤其是 Mysql 数据的存储形式以及索引的设计，决定了 Mysql 整体的数据检索性能。

我们知道，索引的作用是做数据的快速检索，而快速检索的实现的本质是数据结构。通过不同数据结构的选择，实现各种数据快速检索。在数据库中，高效的查找算法是非常重要的，因为数据库中存储了大量数据，一个高效的索引能节省巨大的时间。比如下面这个数据表，如果 Mysql 没有实现索引算法，那么查找 id=7 这个数据，那么只能采取暴力顺序遍历查找，找到 id=7 这个数据需要比较 7 次，如果这个表存储的是 1000W 个数据，查找 id=1000W 这个数据那就要比较 1000W 次，这种速度是不能接受的。

数据库与普通文件系统的一个重要的区别就是；数据库可以在多种故障下仍然可以正确运行，保证系统以及数据的正确性；这些故障包括但不限于数据库系统本身故障，操作系统故障，以及存储介质故障等。那么数据库是如何在这些故障下面还能保证系统和数据的正确性的呢？主要靠Redo Log和Undo Log日志与WAL(Write Ahead Log)机制的配合来支持，其理论支持在论文《ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging》中介绍的非常详细。

金融企业在生产安全的前提下，如何确保MySQL的开发合规和性能管控？

通过本文这个案例你会发现整个数据库体系还有很多内容值得去学习，试想一下，如果平时对主从复制的原理比较熟的话，问题排查起来也会简单很多。

如何打造一个稳定、高效的Mysql Binlog实时接入服务。

客户发现一个非预期内的锁等待现象，用户贼郁闷，隔离级别用的是 RC，两个session又都只更新一条数据，并且更新的还是两条不一样的数据，按理来说没有冲突，不应该造成阻塞。

InnoDB 存储引擎中所有可变长度类型的字段（如 VARCHAR、VARBINARY、BLOB 和 TEXT）可以存储在主键记录内，也可以存储在主键记录之外的单独 BLOB 页中（在同一表空间内）。所有这些字段都可以归类为大对象。这些大对象要么是二进制大对象，要么是字符大对象。二进制大对象没有关联的字符集，而字符大对象有。在 InnoDB 存储引擎中，字符大对象和二进制大对象的处理方式没有区别，我们使用“BLOB”来指代上述的大对象字段。BLOB不同大小，不同场景，可以全部存储在主键，部分前缀存储在主键，或者全部存储在外部BLOB页中，本篇文章主要集中在BLOB全部存储在外部BLOB页中时，在innodb中是如何实现的，其他的在主键内部或者前缀在主键内部不再展开说明。只有主键可以在外部存储 BLOB 字段，二级索引不能有外部存储的字段，本文的讨论都是围绕着主键展开。

无论从使用、研发还是运维的角度，内存监控一直是MySQL的重点之一。完善的内存监控手段有很多作用。