泽民博客 ☰ Menu

mariadb

https://mariadb.com/kb/zh-cn/mariadb-mariadbmysql/
MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。



MariaDB由MySQL的创始人麦克尔·维德纽斯主导开发
MariaDB直到5.5版本，均依照MySQL的版本。因此，使用MariaDB5.5的人会从MySQL5.5中了解到MariaDB的所有功能。从2012年11月12日起发布的10.0.0版开始，不再依照MySQL的版号。10.0.x版以5.5版为基础，加上移植自MySQL 5.6版的功能和自行开发的新功能。



在存储引擎方面，10.0.9版起使用XtraDB（名称代号为Aria）来代替MySQL的InnoDB。



MariaDB的API和协议兼容MySQL，另外又添加了一些功能，以支持本地的非阻塞操作和进度报告。

MySQL体系结构
MySQL服务器基于分层架构，由主要子系统和支持组件组成，它们通过相互交互来读取，解析和执行查询以返回结果。



MySQL的五种主要子系统是：



查询引擎
存储管理器
缓冲管理器
事务管理器
恢复管理器
查询引擎：它包含三个主要的相关组件 - 语法分析器，查询优化器和执行组件。语法分析器以一种MySQL引擎能够理解的形式分解从调用程序接收到的SQL命令。“查询优化器”简化执行组件使用的语法，然后为查询执行准备最有效的计划。执行组件根据它接收的信息解释执行计划，并向其他组件提出请求以检索记录。



存储管理器：与操作系统连接，以用户表，索引和日志以及内部系统数据的形式将数据写入磁盘。



查询缓存： MySQL引擎使用查询缓存–极其高效的结果集缓存机制，这极大地减少了查询的响应时间，这些查询被调用当检索与先前查询相同的数据。



缓冲区管理器：处理查询引擎和存储管理器对数据请求之间的所有内存管理问题。MySQL使用内存来缓存可以返回的结果集，并且缓存被保存在缓冲区管理器中。



事务管理器：这个子系统提供了锁定功能，以确保多个用户以一致的方式访问数据，而不会损坏或破坏数据。



恢复管理器：为了在发生任何类型的数据丢失的情况下进行检索，会保留数据的副本。



MySQL的两个支持组件是：



进程管理
函数库
进程管理器：它执行两个主要功能 – 管理通过网络连接的用户，以及通过多线程，线程锁定和执行线程安全操作同步任务和进程。



函数库：它包含通用的函数，如字符串操作，排序操作和执行特定于操作系统的函数，如内存管理和文件I / O。



MySQL的特点
关系数据库管理系统：
MySQL支持所有功能，这使得它成为一个完整的关系数据库管理系统（RDBMS）。它支持完整的SQL作为查询和更新数据的标准化语言，并且可以管理数据库。
简单而安全：与其他数据库管理系统（DBMS）软件相比，MySQL使用非常简单且具有交互性，并且具有可靠的数据安全层，可为数据提供高效的加密，因此非常安全。
客户机/服务器体系结构：其简单的客户机/服务器体系结构可帮助终端用户创建一个与许多客户机连接的服务器，以便与服务器进行通信进行插入，更新和管理数据库。
可伸缩性： MySQL可以处理大量数据而不会出现任何卡顿 – 多达5000万行。它可以处理高达8TB的数据而没有任何问题。
跨平台：与几乎所有操作系统兼容，如UNIX，Windows，Linux，MAC OS X等。
高性能，灵活且高效的生产力：
MySQL提供更快速，高度可靠，便宜的存储解决方案，并支持大量嵌入式应用程序。它利用触发器，程序和视图来提高生产力。



MySQL和MariaDB之间的一些重要差异



数据库的使用情况：自1995年以来，MySQL一直被视为迄今为止实施最为广泛且最广泛使用的开源数据库。许多像Twitter，YouTube，Netflix和PayPal这样的IT巨头，以及美国国家航空航天局，美国国防部队和沃尔玛都利用这个数据库。
最近才到来的MariaDB也在各种IT巨头组织（如Google，Red Hat，CentOS和Fedora）中作为后端软件因此得到了强大的基础。



数据库和索引的结构： MySQL是一个纯粹的关系数据库，集成了一个ANSI标准的信息模式，由表，列，视图，过程，触发器，游标等组成。MySQL的结构化查询语言（SQL）是ANSI SQL 99。
而MariaDB是MySQL的一个分支，因此具有相同的数据库结构和索引。该功能使MariaDB成为希望直接切换或升级后端的用户的理想选择，而无需升级数据库和数据结构。



当从MySQL升级到MariaDB时，所有内容（从数据，表格定义，结构和API）都保持一致。



二进制和实现： MySQL是使用C和C ++开发的，并且完全兼容几乎所有操作系统，如Microsoft Windows，MAC OS X，Linux，FreeBSD，UNIX，NetBSD，Novell Netware和其他许多操作系统。
MariaDB使用C，C ++，Bash和Perl开发。它与Microsoft Windows，Linux，MAC OS X，FreeBSD，Solaris等各种操作系统兼容。



复制和集群： MySQL通过主从主复制和主从复制提供强大的复制和集群，并利用Galera集群实现多主集群。
MariaDB为主终端用户提供与主从主复制和主从复制相同的复制和集群功能。它还使用10.1版以后的Galera Cluster。



对数据库的支持：通过Oracle全天候提供MySQL技术支持服务，支持团队由专业开发人员和工程师组成，他们提供各种工具，如错误修复，修补程序和版本发布。Oracle根据用户的需求提供MySQL首要支持，扩展支持和持续支持。
MariaDB通过开源社区，在线论坛甚至通过专家为用户提供强有力的支持。MariaDB通过企业订阅提供24小时全天候支持，尤其适用于任务关键型生产系统。



安全性：就安全性而言，MySQL为表空间数据提供了强大的加密机制。它提供了强大的安全参数，包括选择好的密码，不给用户不必要的特权，并通过防止SQL注入和数据损坏来确保应用程序安全。
MariaDB在内部安全和密码检查，验证模块（PAM）和轻量级目录访问协议（LDAP）认证，Kerberos，用户角色以及对表空间，表格和日志的强大加密等安全功能方面取得了重大进展。



可扩展性：支持可扩展系统的数据库可以用许多不同的方式进行扩展，如添加新的数据类型，函数，运算符，聚集函数，索引方法和过程语言。MySQL不支持可扩展性。
MariaDB建立在现代架构的基础之上，可以在每一层 – 客户端，集群，内核和存储上进行扩展。这种可扩展性提供了两个主要优势。它允许通过插件实现持续的社区创新，这意味着可以通过MariaDB的可扩展架构集成各种存储引擎，如MariaDB ColumnStore或Facebook的MyRocks。此外，它使客户能够轻松配置MariaDB以支持从联机事务处理（OLTP）到联机分析处理（OLAP）的各种用例。



JSON支持： MySQL支持本地JSON数据类型，可以在JSON（JavaScript Object Notation）文档中高效地访问数据。与将JSON格式的字符串存储在字符串列中相比，JSON数据类型提供了以下优点：
自动验证存储在JSON列中的JSON文档。无效的文档会产生错误。
优化的存储格式：存储在JSON列中的JSON文档被转换为允许快速读取文档元素的内部格式。当服务器稍后必须读取以这种二进制格式存储的JSON值时，不需要从文本表示中解析该值。二进制格式的结构使服务器能够直接通过键或数组索引查找子对象或嵌套值，而无需读取文档中的所有值。
另一方面，MariaDB Server 10.2引入了一整套用于读写JSON文档的24个函数。另外，JSON_VALID函数可以与校验约束一起使用，而像JSON_VALUE这样的函数可以与动态列一起使用来索引特定的字段。



授权许可： MySQL在GPL下以开放源代码提供代码，并以MySQL Enterprise形式提供非GPL商业分发选项。
MariaDB只能使用GPL，因为它的工作源于该许可条款下的MySQL源代码。



性能： MariaDB通过MySQL的许多创新实现了同类最佳性能。其中包括线程池管理以最大限度地提高处理效率，以及InnoDB数据存储区内的碎片整理等广泛的优化功能。因此，当从InnoDB表中删除行时，可用空间立即可供操作系统使用。不需要将旧表中的数据复制到新表中，并且表空间中没有空闲。MariaDB还提供与引擎无关的表统计信息，以改善优化程序的性能，加快对表的大小和结构进行查询处理和数据分析。
如果没有这些增强功能，MySQL的性能就会下降。MySQL中的线程利用率是次优的，InnoDB表随着时间的推移变得碎片化，从而影响性能。



MariaDB与MySQL
以下几点突出了MariaDB的优缺点。



优点
MariaDB针对性能进行了优化，对于大型数据集，它比MySQL强大得多。从其他数据库系统可以优雅的迁移到MariaDB是另一个好处。
从MySQL切换到MariaDB相对容易，这对于系统管理员来说好像是一块蛋糕。
MariaDB通过引入微秒级精度和扩展用户统计数据提供更好的监控。
MariaDB增强了KILL命令，使您可以杀死用户的所有查询（KILL USER 用户名）或杀死查询ID（KILL QUERY ID query_id）。MariaDB也转而使用Perl兼容的正则表达式（PCRE），它提供比标准MySQL正则表达式支持更强大和更精确的查询。
MariaDB为与磁盘访问，连接操作，子查询，派生表和视图，执行控制甚至解释语句相关的查询应用了许多查询优化。
MariaDB纯粹是开源的，而不是MySQL使用的双重授权模式。一些仅适用于MySQL
Enterprise客户的插件在MariaDB中具有等效的开源实现。
与MySQL相比，MariaDB支持更多的引擎（SphinxSE，Aria，FederatedX，TokuDB，Spider，ScaleDB等）。
MariaDB提供了一个用于商业用途的集群数据库，它也支持多主复制。任何人都可以自由使用它，并且不需要依赖MySQL
Enterprise系统。
缺点
从版本5.5.36开始，MariaDB无法迁移回MySQL。
对于MariaDB的新版本，相应的库（用于Debian）不会及时部署，由于依赖关系，这将导致必需升级到较新的版本。
MariaDB的群集版本不是很稳定。
迁移到MariaDB的主要原因
首先，MariaDB提供了更多更好的存储引擎。NoSQL支持由Cassandra提供，允许您在单个数据库系统中运行SQL和NoSQL。MariaDB还支持TokuDB，它可以处理大型组织和企业用户的大数据。
MySQL的平常（和缓慢的）数据库引擎MyISAM和InnoDB已分别在MariaDB中由Aria和XtraDB取代。Aria提供了更好的缓存，这对于磁盘密集型操作来说是有所不同的。
MariaDB通过引入微秒级精度和扩展用户统计数据提供更好的监控。
MariaDB的最新功能（如GIS，动态色谱柱支持等）使其成为更好的选择。
MariaDB遵循良好的行业标准，同时发布安全公告和升级，并以正确的方式处理预发布的保密性和发布后的透明度。




  1. JSON 数据类型——从 5.7 版本开始，MySQL 支持由 RFC 7159 定义的原生 JSON 数据类型，可以高效地访问 JSON 文档中的数据。



MariaDB 没有提供这一增强功能，认为 JSON 数据类型不是 SQL 标准的一部分。但为了支持从 MySQL 复制数据，MariaDB 为 JSON 定义了一个别名，实际上就是一个 LONGTEXT 列。MariaDB 声称两者之间没有显著的性能差异，但他们并没有提供基准测试数据来支持这个说法。



值得注意的是，MySQL 和 MariaDB 都提供了一些 JSON 相关函数，用于更方便地访问、解析和检索 JSON 数据。





  1. 默认身份认证——在 MySQL 8.0 中，默认的身份认证插件是 caching_sha2_password，而不是 mysql_native_password。这一增强通过使用 SHA-256 算法提高了安全性。




  2. MySQL Shell——MySQL Shell 是 MySQL 的高级命令行客户端和代码编辑器。除了 SQL 之外，MySQL Shell 还提供了 JavaScript 和 Python 脚本功能。不过用户不能使用 mysqlsh 访问 MariaDB 服务器，因为 MariaDB 不支持 MySQL X 协议。




  3. 加密——MySQL 对重做 / 撤消日志进行了加密（可配），但不加密临时表空间或二进制日志。相反，MariaDB 支持二进制日志和临时表加密。




  4. 密钥管理——MariaDB 提供开箱即用的 AWS 密钥管理插件。MySQL 也提供了一些用于密钥管理的插件，但它们仅在企业版中可用。




  5. sys 模式——MySQL 8.0 提供了 sys 模式，这是一组对象，可帮助数据库管理员和软件工程师更好地理解通过 Performance 模式收集的数据。sys 模式对象可用于优化和诊断，不过 MariaDB 没有提供这个增强功能。




  6. validate_password 插件——validate_password 插件主要用于测试密码并提高安全性。MySQL 默认启用了这个插件，而 MariaDB 则不启用。




  7. 超级只读—— MySQL 通过提供超级只读（super read-only）模式来增强 read_only 功能。如果启用了 read_only，服务器只允许具有 SUPER 权限的用户执行客户端更新。如果同时启用了 super_read_only，那么服务器将禁止具有 SUPER 权限的用户执行客户端更新。




  8. 不可见列——这个功能在 MariaDB 上可用，MySQL 不支持该功能。这个功能允许创建未在 SELECT * 语句中出现的列，而在进行插入时，如果它们的名字没有出现在 INSERT 语句中，就不需要为这些列提供值。




  9. 线程池——MariaDB 支持连接线程池，这对于短查询和 CPU 密集型的工作负载（OLTP）来说非常有用。在 MySQL 的社区版本中，线程数是固定的，因而限制了这种灵活性。MySQL 计划在企业版中增加线程池功能。





性能



近年来，出现了很多关于 MySQL 和 MariaDB 引擎性能的基准测试。我们不认为“MySQL 或 MariaDB 哪个更快”这个问题会有一个最终的答案，它在很大程度上取决于具体的使用场景、查询、用户和连接数量等因素。



不过，如果你确实想知道，下面列出了我们发现的一些最新的基准测试结果。请注意，这些测试都是在一组特定的数据库 + 引擎（例如 MySQL+InnoDB）组合上进行的，因此得出的结论只与特定的组合有关。



MySQL 8.0（InnoDB）和 MariaDB 10.3.7（MyRocks）基准测试对比：



https://minervadb.com/index.php/2018/06/01/benchmarking-innodb-and-myrocks-performance-using-sysbench/



MariaDB 10.1 和 MySQL 5.7 在商用硬件上的性能对比：



https://mariadb.org/maria-10-1-mysql-5-7-commodity-hardware/



MySQL 8.0 和 MariaDB 10.3.5 性能对比及 UTF8 的影响：



http://dimitrik.free.fr/blog/archives/2018/04/mysql-performance-80-and-utf8-impact.html



复制



两个数据库都提供了将数据从一个服务器复制到另一个服务器的功能。它们的主要区别是大多数 MariaDB 版本允许你从 MySQL 复制数据，这意味着你可以轻松地将 MySQL 迁移到 MariaDB。但反过来却没有那么容易，因为大多数 MySQL 版本都不允许从 MariaDB 复制数据。



此外，值得注意的是，MySQL GTID 不同于 MariaDB GTID，所以将数据从 MySQL 复制到 MariaDB 后，GTID 数据将相应地做出调整。



以下是这两个数据库在复制配置方面的一些差别：



MySQL 的默认二进制日志格式是基于行的，而在 MariaDB 中，默认的二进制日志格式是混合式的。



log_bin_compress——这个配置决定了是否可以压缩二进制日志。这个增强功能是 MariaDB 独有的，因此 MySQL 不支持。



两者之间的不兼容性



MariaDB 的文档中列出了 MySQL 和 MariaDB 之间的数百个不兼容问题。因此，我们无法通过简单的方案在这两个数据库之间进行迁移。



大多数数据库管理员都希望 MariaDB 只是作为 MySQL 的一个 branch，这样就可以轻松地在两者之间进行迁移。但从最新发布的几个版本来看，这种想法是不现实的。MariaDB 实际上是 MySQL 的一个 fork，这意味着在它们之间进行迁移需要考虑很多东西。



存储引擎



MariaDB 比 MySQL 支持更多的存储引擎类型。但话说回来，数据库可以支持多少个存储引擎并不重要，重要的是哪个数据库可以支持适合你需求的存储引擎。



MariaDB 支持的存储引擎包括：XtraDB、InnoDB、MariaDB ColumnStore、Aria、Archive、Blackhole、Cassandra Storage Engine、Connect、CSV、FederatedX、Memory、Merge、Mroonga、MyISAM、MyRocks、QQGraph、Sequence Storage Engine、SphinxSE、Spider、TokuDB。



MySQL 支持的存储引擎包括：InnoDB、MyISAM、Memory、CSV、Archive、Blackhole、Merge、Federated、Example。



在 Linux 上安装



当你在某些 Linux 发行版上安装 MySQL 时，最后可能安装的是 MariaDB，因为它是很多（不是全部）Linux 发行版的默认设置。



Red Hat Enterprise/CentOS/Fedora/Debian 发行版默认会安装 MariaDB，而其他发行版（如 Ubuntu）默认安装 MySQL。



云平台上的可用性



MariaDB 可作为运行在 Amazon Web Services（AWS）、微软 Azure 和 Rackspace Cloud 上的服务。



MySQL 在上面提到的三个平台上也是可用的，同时还可以作为托管服务在谷歌云服务平台上运行。



因此，如果你正在使用谷歌云平台，并希望云提供商为你管理服务，那么可以考虑使用 MySQL，除非你希望自己安装和管理 MariaDB 实例。



许可



MariaDB 采用了 GPL v2 许可，而 MySQL 提供了两个许可选项——GPL v2（用于社区版）和企业许可。



MySQL 的两个许可之间的主要区别在于可用的功能和支持服务。用户可以使用 MariaDB 的所有功能，但对于 MySQL 来说并非如此。MySQL 的社区版不包含线程池等功能，而这些功能会对数据库和查询性能产生重大影响。



发布频率和更新



通常，MariaDB 的发布频率比 MySQL 更频繁。太高的发布频率既有利也有弊。从好的方面来说，用户可以更及时地收到功能和错误修复。从不好的方面来说，为了让 MariaDB 保持最新的状态，需要更多的工作量。



技术支持



MySQL 的支持团队（包括 MySQL 开发人员和支持工程师）为客户提供全天候服务。甲骨文提供了多种支持选项，包括扩展支持、持续支持和高级支持，具体取决于客户的要求。MariaDB 支持团队的支持工程师包括了 MariaDB 和 MySQL 数据库专家（因为很多功能最初是由 MySQL 团队开发的），他们为生产系统提供全天候的企业级支持。



正在进行中的开发



MySQL 的开发者主要是甲骨文的 MySQL 团队，而 MariaDB 开发通过公开投票和邮件列表讨论的方式进行。此外，任何人都可以向 MariaDB 提交补丁，MariaDB 开发团队会考虑将这些补丁添加到主代码库中。因此，从某种程度上说，MariaDB 是由社区开发的，而 MySQL 主要由甲骨文开发。



MariaDB 10.2是当前MariaDB主要版本（2017），支持生命周期到2022年。现在新GA版本： MairaDB 10.2.6 GA。



下面看看MariaDB 10.2版本新的重要特性：



一、官方InnoDB成为默认引擎



MariaDB 10.1及之前版本均使用Percona XtraDB做为默认引擎，而MariaDB 10.2则使用了MySQL官方的InnoDB做为默认引擎，原来使用的XtraDB引擎的也可以直接升级，不受影响。新版本放弃XtraDB引擎的原因如下：





  1. XtraDB引擎在MySQL 5.1, 5.5时非常优秀，但在最近几年官方几乎把所有优秀的特性都实现了。




  2. 本次在MariaDB 10.2中合并MySQL InnoDB用了差不多半年多的时间，这是一个非常复杂的工作。MairaDB觉得，此版本再去合并XtraDB对用户带来的效益不大。




  3. 再看XtraDB 5.7的改动，只是优化了密集IO写入处理，可以通过适当调整





innodb_thread_concurrency等其他选项来达到相同效果，但如果把XtraDB做一个整体的代码合并，MariaDB 10.2发布还要晚半年之久。




  1. 以后不是说全面放弃XtraDB，只是不把XtraDB的全部代码合并，只把其优秀的特性做为Patch合并过来。



二、语法/常规特性





  1. MyRocks 做为一个Alpha引擎合并进来。 虽然是一个Alpha版本，但对于想试一下MyRocks的同学，这是一个好事，可以直接用来体验一下。[不过还是暂不推荐在生产上使用]。




  2. 窗口函数(windows function）引入。




  3. show create user语句引入。




  4. 新的create user语句，可以引入资源限制。




  5. 新的alter user语句。




  6. 递归公共表表达式（Recursive Common Table Expressions）。




  7. 新的with语句, With也是一个公共表式中的一个种，允许子查询。




  8. 支持check constranint。




  9. 支持 default with表达式。




  10. BLOB & TEXT列支持默认值。




  11. Virtual例，去除了很多限制。




  12. decimal小数点位从原来的30增加到38。




  13. 对list分区添加一个catchall特性，有点类似于Range分区中的maxvalue，对于list分区放不下了，就放到这个catchall这个分区。




  14. Oracle 格式的execute immediate语句实现。




  15. prepare语句可以识别更多的表达式。




  16. InnoDB表支持spatial indexes。




  17. ed25519 authentication plugin。




  18. 更好的InnoDB crash recovery进程汇报。




  19. 改进InnoDB的开启关闭实现使它更建壮。




  20. 支持windows, centos, rehl下面的 AWS Key Management plugin。





三、不兼容的更改




  1. TokuDB 不在默认包里发布，如果需要使用，请下载mariadb-plugin-tokudb。对于已使用MariaDB TokuDB升级的同学会稍微麻烦些。



【作者备注：有点遗憾，MariaDB把TokuDB踢出。现在Percona下的TokuDB开发也是几个华人在做，另外国内也有一个分支版本，基于Percona的TokuDB进行优化并且在xtrabackup上实现热备，项目地址：https://github.com/XeLabs/tokudb，使用TokuDB的也可以关注一下。需要交流的，也可以加QQ群：579036588 备注 TokuDB入群。】





  1. SQL_MODE has been changed; in particular, NOT NULL fields with no default will no longer fall back to a dummy value for inserts which do not specify a value for that field。




  2. Replication from legacy MySQL servers may require setting binlog_checksum to NONE。





四、Replication/Binary log





  1. 支持DML对实例库表进行flashback操作。




  2. 新的参数: read_binlog_speed_limit 用于限制从库和主库日志相差太远，需要大量的从master上获取日志造成主库的网卡，IO性能受影响( Original code from Tencent Game DBA Team, developed by chouryzhou)。




  3. 支持延迟复制Delayed Replication。




  4. 支持压缩的binlog Event。 （Original code from Tencent Game DBA Team, developed by vinchen.）




  5. 把默认的binlog格式改成mixed [建议实际使用，还是使用row]。




  6. 参数：replication_annote_row_events默认改成：on。




  7. 把参数slave_net_timeout进行减小，改到：60成为默认值。




  8. 把参数server-id的值由原来0改成1。





1995年，MySQL 1.0发布，仅供内部使用。



1996年，MySQL 3.11.1发布，直接跳过了MySQL 2.x版本。



1999年，MySQL AB公司成立。同年，发布MySQL 3.23，该版本集成了Berkeley DB存储引擎。该引擎由Sleepycat公司开发，支持事务。在集成该引擎的过程中，对源码进行了改造，为后续可插拔式存储引擎架构奠定了基础。



2000年，ISAM升级为MyISAM存储引擎。同年，MySQL基于GPL协议开放源码。



2002年，MySQL 4.0发布，集成了后来大名鼎鼎的InnoDB存储引擎。该引擎由Innobase公司开发，支持事务，支持行级锁，适用于OLTP等高并发场景。



2005年，MySQL 5.0发布，开始支持游标，存储过程，触发器，视图，XA事务等特性。同年，Oracle收购Innobase公司。



2008年，Sun以10亿美金收购MySQL AB。同年，发布MySQL 5.1，其开始支持定时器（Event scheduler），分区，基于行的复制等特性。



2009年，Oracle以74亿美金收购Sun公司。



2010年，MySQL 5.5发布，其包括如下重要特性及更新。



InnoDB代替MyISAM成为MySQL默认的存储引擎。
多核扩展，能更充分地使用多核CPU。
InnoDB的性能提升，包括支持索引的快速创建，表压缩，I/O子系统的性能提升，PURGE操作从主线程中剥离出来，Buffer Pool可拆分为多个Instances。
半同步复制。
引入utf8mb4字符集，可用来存储emoji表情。
引入metadata locks（元数据锁）。
分区表的增强，新增两个分区类型：RANGE COLUMNS和LIST COLUMNS。
MySQL企业版引入线程池。
可配置IO读写线程的数量（innodb_read_io_threads，innodb_write_io_threads）。在此之前，其数量为1，且不可配置。
引入innodb_io_capacity选项，用于控制脏页刷新的数量。



2013年，MySQL 5.6发布，其包括如下重要特性及更新。



GTID复制。
无损复制。
延迟复制。
基于库级别的并行复制。
mysqlbinlog可远程备份binlog。
对TIME, DATETIME和TIMESTAMP进行了重构，可支持小数秒。DATETIME的空间需求也从之前的8个字节减少到5个字节。
Online DDL。ALTER操作不再阻塞DML。
可传输表空间（transportable tablespaces）。
统计信息的持久化。避免主从之间或数据库重启后，同一个SQL的执行计划有差异。
全文索引。
InnoDB Memcached plugin。
EXPLAIN可用来查看DELETE，INSERT，REPLACE，UPDATE等DML操作的执行计划，在此之前，只支持SELECT操作。
分区表的增强，包括最大可用分区数增加至8192，支持分区和非分区表之间的数据交换，操作时显式指定分区。
Redo Log总大小的限制从之前的4G扩展至512G。
Undo Log可保存在独立表空间中，因其是随机IO，更适合放到SSD中。但仍然不支持空间的自动回收。
可dump和load Buffer pool的状态，避免数据库重启后需要较长的预热时间。
InnoDB内部的性能提升，包括拆分kernel mutex，引入独立的刷新线程，可设置多个purge线程。
优化器性能提升，引入了ICP，MRR，BKA等特性，针对子查询进行了优化。
可以说，MySQL 5.6是MySQL历史上一个里程碑式的版本，这也是目前生产上应用得最广泛的版本。



2015年，MySQL 5.7发布，其包括如下重要特性及更新。



组复制
InnoDB Cluster
多源复制
增强半同步（AFTER_SYNC）
基于WRITESET的并行复制。
在线开启GTID复制。
在线设置复制过滤规则。
在线修改Buffer pool的大小。
在同一长度编码字节内，修改VARCHAR的大小只需修改表的元数据，无需创建临时表。
可设置NUMA架构的内存分配策略（innodb_numa_interleave）。
透明页压缩（Transparent Page Compression）。
UNDO表空间的自动回收。
查询优化器的重构和增强。
可查看当前正在执行的SQL的执行计划（EXPLAIN FOR CONNECTION）。
引入了查询改写插件（Query Rewrite Plugin），可在服务端对查询进行改写。
EXPLAIN FORMAT=JSON会显示成本信息，这样可直观的比较两种执行计划的优劣。
引入了虚拟列，类似于Oracle中的函数索引。
新实例不再默认创建test数据库及匿名用户。
引入ALTER USER命令，可用来修改用户密码，密码的过期策略，及锁定用户等。
mysql.user表中存储密码的字段从password修改为authentication_string。
表空间加密。
优化了Performance Schema，其内存使用减少。
Performance Schema引入了众多instrumentation。常用的有Memory usage instrumentation，可用来查看MySQL的内存使用情况，Metadata Locking Instrumentation，可用来查看MDL的持有情况，Stage Progress instrumentation，可用来查看Online DDL的进度。
同一触发事件（INSERT，DELETE，UPDATE），同一触发时间（BEFORE，AFTER），允许创建多个触发器。在此之前，只允许创建一个触发器。
InnoDB原生支持分区表，在此之前，是通过ha_partition接口来实现的。
分区表支持可传输表空间特性。
集成了SYS数据库，简化了MySQL的管理及异常问题的定位。
原生支持JSON类型，并引入了众多JSON函数。
引入了新的逻辑备份工具-mysqlpump，支持表级别的多线程备份。
引入了新的客户端工具-mysqlsh，其支持三种语言：JavaScript, Python and SQL。两种API：X DevAPI，AdminAPI，其中，前者可将MySQL作为文档型数据库进行操作，后者用于管理InnoDB Cluster。
mysql_install_db被mysqld –initialize代替，用来进行实例的初始化。
原生支持systemd。
引入了super_read_only选项。
可设置SELECT操作的超时时长（max_execution_time）。
可通过SHUTDOWN命令关闭MySQL实例。
引入了innodb_deadlock_detect选项，在高并发场景下，可使用该选项来关闭死锁检测。
引入了Optimizer Hints，可在语句级别控制优化器的行为，如是否开启ICP，MRR等，在此之前，只有Index Hints。
GIS的增强，包括使用Boost.Geometry替代之前的GIS算法，InnoDB开始支持空间索引。



2018年，MySQL 8.0发布，其包括如下重要特性及更新。



引入了原生的，基于InnoDB的数据字典。数据字典表位于mysql库中，对用户不可见，同mysql库的其它系统表一样，保存在数据目录下的mysql.ibd文件中。不再置于mysql目录下。
Atomic DDL。
重构了INFORMATION_SCHEMA，其中，部分表已重构为基于数据字典的视图，在此之前，其为临时表。
PERFORMANCE_SCHEMA查询性能提升，其已内置多个索引。
不可见索引（Invisible index）。
降序索引。
直方图。
公用表表达式（Common table expressions）。
窗口函数（Window functions）。
角色（Role）。
资源组（Resource Groups），可用来控制线程的优先级及其能使用的资源，目前，能被管理的资源只有CPU。
引入了innodb_dedicated_server选项，可基于服务器的内存来动态设置innodb_buffer_pool_size，innodb_log_file_size和innodb_flush_method。
快速加列（ALGORITHM=INSTANT）。
JSON字段的部分更新（JSON Partial Updates）。
自增主键的持久化。
可持久化全局变量（SET PERSIST）。
默认字符集由latin1修改为utf8mb4。
默认开启UNDO表空间，且支持在线调整数量（innodb_undo_tablespaces）。在MySQL 5.7中，默认不开启，若要开启，只能初始化时设置。
备份锁。
Redo Log的优化，包括允许多个用户线程并发写入log buffer，可动态修改innodb_log_buffer_size的大小。
默认的认证插件由mysql_native_password更改为caching_sha2_password。
默认的内存临时表由MEMORY引擎更改为TempTable引擎，相比于前者，后者支持以变长方式存储VARCHAR，VARBINARY等变长字段。从MySQL 8.0.13开始，TempTable引擎支持BLOB字段。
Grant不再隐式创建用户。
SELECT … FOR SHARE和SELECT … FOR UPDATE语句中引入NOWAIT和SKIP LOCKED选项，解决电商场景热点行问题。
正则表达式的增强，新增了4个相关函数，REGEXP_INSTR()，REGEXP_LIKE()，REGEXP_REPLACE()，REGEXP_SUBSTR()。
查询优化器在制定执行计划时，会考虑数据是否在Buffer Pool中。而在此之前，是假设数据都在磁盘中。
ha_partition接口从代码层移除，如果要使用分区表，只能使用InnoDB存储引擎。
引入了更多细粒度的权限来替代SUPER权限，现在授予SUPER权限会提示warning。
GROUP BY语句不再隐式排序。
MySQL 5.7引入的表空间加密特性可对Redo Log和Undo Log进行加密。
information_schema中的innodb_locks和innodb_lock_waits表被移除，取而代之的是performance_schema中的data_locks和data_lock_waits表。
引入performance_schema.variables_info表，记录了参数的来源及修改情况。
增加了对于客户端报错信息的统计（performance_schema.events_errors_summary_xxx）。
可统计查询的响应时间分布（call sys.ps_statement_avg_latency_histogram()）。
支持直接修改列名（ALTER TABLE … RENAME COLUMN old_name TO new_name）。
用户密码可设置重试策略（Reuse Policy）。
移除PASSWORD()函数。这就意味着无法通过“SET PASSWORD … = PASSWORD(‘auth_string’) ”命令修改用户密码。
代码层移除Query Cache模块，故Query Cache相关的变量和操作均不再支持。
BLOB, TEXT, GEOMETRY和JSON字段允许设置默认值。
可通过RESTART命令重启MySQL实例。



Category storage