数据库与普通文件系统的一个重要的区别就是；数据库可以在多种故障下仍然可以正确运行，保证系统以及数据的正确性；这些故障包括但不限于数据库系统本身故障，操作系统故障，以及存储介质故障等。那么数据库是如何在这些故障下面还能保证系统和数据的正确性的呢？主要靠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的重点之一。完善的内存监控手段有很多作用。

用 go-mysql-elasticsearch 实现数据同步的本地化实践。

对于一个服务端开发来说 MYSQL 可能是他使用最熟悉的数据库工具，然而，大部分的Java工程师对MySQL的了解和掌握程度，大致就停留在这么一个阶段:它可以建库、建表、建索引，然后就是对里面的数据进行增删改查，语句性能有点差？没关系，在表里建几个索引或者调整一下查询逻辑就可以了，一条sql，MYSQL是如何处理的，为我们做了什么，完全是个黑盒。本文主要通过sql执行的过程打破这样一个黑盒的认知，来了解MYSQL的逻辑架构。

分享有关悬挂事物的相关知识及一例生产环境中的关于悬挂事务的案例。

MySQL等值查询，可能并不是你想的那么简单，还跟校对规则有对，具体细节且听本文娓娓道来。

Uber uses MySQL as the underlying database engine for Schemaless and Docstore, our distributed databases. By default, MySQL uses the most popular InnoDB engine, a B+Tree structure for data storage. MyRocks is a MySQL storage engine that integrates with RocksDB, an open source project. The RocksDB store is based on the log-structured merge-tree (or LSM tree) and is optimized for fast storage and combines outstanding space and write efficiency with acceptable read performance.

The Uber Storage Platform team has migrated all Schemaless instances and some Docstore instances to MyRocks since 2019. In this post, we are going to talk about the journey of our migration to MyRocks.

innodb支持空间索引，但很少有关于innodb关于空间索引的实现的介绍文章，本篇文章主要目的是介绍innodb关于空间索引的源码介绍，知其所以然。空间索引本质上是二级索引中的一种，基于R树实现。

innodb索引主要是基于B+树实现，B+树是一棵平衡树，是把一维直线分为若干段线段，当我们查找满足某个要求的点的时候，只要去查找它所属的线段即可。这种思想其实就是先找一个大的空间，再逐步缩小所要查找的空间，最终在一个自己设定的最小不可分空间内找出满足要求的解。B+树是解决低纬度数据（通常一维，也就是一个数据维度上进行比较），R树很好的解决了高维空间搜索问题。它把B树的思想很好的扩展到了多维空间，采用了B树分割空间的思想（如果B树在一维的线段进行分割，R树就是在二维甚至多维度的空间），并在添加、删除操作时采用合并、分解结点的方法，保证树的平衡性。因此，R树就是一棵用来存储高维数据的平衡树。

为了保障数据安全，MySQL 在 5.7 版本就支持了 InnoDB 表空间加密，之前写了一篇月报介绍过，参考InnoDB 表空间加密。文章开头也提到过，MariaDB 除了对表空间加密，也可以对 redo log 和 binlog 加密，本质上 redo log 和 binlog 中也保存着明文的数据，如果文件被拖走数据也有丢失的风险，因此在 MySQL 8.0 中也支持两种日志的加密，本文介绍 Binlog 的加密方式，建议先了解一下表空间加密，更容易理解。

InnoDB 表空间加密是在引擎内部数据页级别的加密手段，在数据页写入文件系统时加密，从文件读到内存中时解密，目前广泛使用的是 YaSSL/OpenSSL 提供的 AES 加密算法，加密前后数据页大小不变，因此也称为透明加密。表空间加密相对于文件系统加密更加灵活，用户可以控制加密重要的表，防止被拖库导致的数据丢失。MySQL 官方在 5.7.11 中发布了表空间加密功能，Aliyun RDS 差不多在同时支持了 RDS MySQL 版的表空间加密，通过了“等保三级” 的认证，随后 MariaDB 在 10.1 支持了功能增强版的“表空间加密”，除了表空间，还可以对 Redo log 和 Binlog 进行加密，参考这篇详细介绍。本文将详细介绍官方的实现方式。

InnoDB会将事务执行过程拆分为若干个Mini Transaction（mtr），每个mtr包含一系列如加锁，写数据，写redo，放锁等操作。