MySQL 数据库简介

MySQL 数据库历史及由来

一、名字由来

二、早期历史

1. 1979年，有一个人叫 Monty Widenius, 为一个叫 TcX的小公司 打工，并用 BASIC语言 设计了一个报表工具，可以在 4M主频和 16KB内在的计算机上运行。过了不久，又将此工具，使用C语言重写，移植到Unix平台，当时，它只是一个很底层的面向报表的存储引擎。这个工具叫做Unireg。
2. 1985 年，瑞典的几位志同道合小伙子（以David Axmark 为首） 成立了一家公司，这就是MySQL AB 的前身。这个公司最初并不是为了开发数据库产品，而是在实现他们想法的过程中，需要一个数据库。他们希望能够使用开源的产品。但在当时并没有一个合适的选择，没办法，只能自己动手开发了。 
3. 在最初，他们只是自己设计了一个利用索引顺序存取数据的方法，也就是 ISAM（Indexed Sequential Access Method）存储引擎核心算法的前身，利用 ISAM 结合 mSQL 来实现他们的应用需求。在早期，他们主要是为瑞典的一些大型零售商提供数据仓库服务。在系统使用过程中，随着数据量越来越大，系统复杂度越来越高，ISAM 和mSQL 的组合逐渐不堪重负。在分析性能瓶颈之后，他们发现问题出在 mSQL 上面。不得已，他们抛弃了mSQL，重新开发了一套功能类似的数据存储引擎，这就是 ISAM 存储引擎。大家可能已经注意到他们当时的主要客户是数据仓库，应该也容易理解为什么直至现在，MySQL 最擅长的是查询性能，而不是事务处理（需要借助第三方存储引擎）。
4. 1990年，TcX 的 customer 中开始有人要求要为它的API提供SQL支持，当时，有人想到了直接使用商用数据库算了，但是Monty觉得商用数据库的速度难令人满意。于是，他直接借助于mSQL的代码，将它集成到自己的存储引擎中。但不巧的是，效果并不太好。于是Monty雄心大起，决心自己重写一个SQL支持。

三、近期发展

1. 1996年，MySQL 1.0发布, 在小范围内使用。到了96年10月，MySQL 3.11.1发布了，没有2.x版本。最开始，只提供了Solaris下的二进制版本。一个月后，Linux版本出现了。 此时的MySQL还非常简陋，除了在一个表上做一些Insert，Update，Delete和Select 操作职位，没有其他更多的功能。 
2. 紧接下来的两年里，MySQL依次移植到各个平台下。它发布时，采用的许可策略，有些与众不同：允许免费商用，但是不能将MySQL与自己的产品绑定在一起发布。如果想一起发布，就必须使用特殊许可，意味着要花银子。当然，商业支持也是需要花银子的。其它的，随用户怎么用都可以。这种特殊许可为MySQL带来了一些收入，从而为它的持续发展打下了良好的基础。
3. 1999-2000年，有一家公司在瑞典成立了，叫MySQL AB。 雇了几个人,与Sleepycat合作，开发出了 Berkeley DB引擎, 因为BDB支持事务处理，所以，MySQL从此开始支持事务处理了。
4. 2000年4月，MySQL对旧的存储引擎进行了整理，命名为MyISAM。
5. 2001年，Heikiki Tuuri向MySQL提出建议，希望能集成他们的存储引擎InnoDB，这个引擎同样支持事务处理，还支持行级锁。所以在2001年发布的3.23 版本的时候，该版本已经支持大多数的基本的SQL 操作，而且还集成了MyISAM和InnoDB 存储引擎。MySQL与InnoDB的正式结合版本是4.0。
6. 2004年10月，发布了经典的4.1版本。 2005年10月，有发布了里程碑的一个版本，MySQL 5.0. 在5.0中加入了游标，存储过程，触发器，视图和事务的支持。在5.0 之后的版本里，MySQL明确地表现出迈向高性能数据库的发展步伐。
7. 2008年1月16号 MySQL被Sun公司收购。
8. 2009年04月20日Oracle收购Sun 公司，MySQL 转入Oracle 门下。
9. 2010年04月22 发布MySQL 5.5, MySQLcluster 7.1。
10. 未完待续...

MySQL 数据库最新版

关键字：hash join、InnoDB双写缓冲、二进制日志事务压缩

• 增加了SHOW_ROUTINE权限。使用该权限允许账户在最小权限下备份存储程序。
• 改进hash join。现在可以使用hash join代替BNL，hash join现在支持半连接、反连接、外连接。
• 加入新的索引级别的优化器提示。包括：JOIN_INDEX、NO_JOIN_INDEX、GROUP_INDEX、NO_GROUP_INDEX、ORDER_INDEX、NO_ORDER_INDEX、INDEX 及 NO_INDEX 。新的索引级别的优化器提示可以搭配SELECT， UPDATE和 DELETE语句使用，而以往的无法和DELETE一起使用。
• Performance Schema改良。为了减少错误检测的内存开销，Performance Schema放弃了在全局范围收集会话相关的错误统计信息。此外，针对每个线程，帐户，用户或主机报告的错误摘要中不再包含全局的错误信息。
• SQL语法改良。以前，语句的INTO子句 SELECT可能出现在以下两个位置之一：

SELECT * INTO OUTFILE 'file_name' FROM table_name;
SELECT * FROM table_name INTO OUTFILE 'file_name' FOR UPDATE;

SELECT * FROM table_name FOR UPDATE INTO OUTFILE 'file_name';

... UNION SELECT * FROM table_name INTO OUTFILE 'file_name';
... UNION (SELECT * FROM table_name) INTO OUTFILE 'file_name';
... UNION SELECT * INTO OUTFILE 'file_name' FROM table_name;
... UNION (SELECT * INTO OUTFILE 'file_name' FROM table_name);

• X Plugin改良。在启动中创建管理会话，以供达到客户端连接限制时获取服务器配置。初始化后立即可以访问MySQL系统变量等缺陷修复。
• BLOB类型排序改变。改变了以往的非完整排序，服务器将BLOB类型转换为打包的插件进行排序，经测试，性能得到显著提升。
• InnoDB改良。双写缓冲区的存储从系表空间移至双写文件。将双写缓冲区存储区移出系统表空间可减少写延迟，增加吞吐量并在双写缓冲区页的放置方面提供灵活性。
• 二进制日志事务压缩。从MySQL 8.0.20开始，您可以在MySQL服务器实例上启用二进制日志事务压缩。启用二进制日志事务压缩后，将使用zstd算法压缩事务有效负载，然后将其作为单个事件（Transaction_payload_event）写入服务器的二进制日志文件 。压缩后的事务有效负载在复制流中发送到从服务器，其他群组复制组成员或客户端（例如mysqlbinlog）时，保持压缩状态 。它们不会被接收器线程解压缩，并且仍以其压缩状态写入中继日志。因此，二进制日志事务压缩既可以节省事务的始发者，也可以节省接收者（及其备份）的存储空间，并在服务器实例之间发送事务时节省网络带宽。
• CHANGE MASTER TO语句的新选项REQUIRE_TABLE_PRIMARY_KEY_CHECK使复制的从服务器可以选择自己的策略来进行主键检查。
• MySQL 8.0.19开始，通过X协议连接发送的消息已支持压缩。MySQL 8.0.19开始，通过X协议连接发送的消息已支持压缩。在MySQL 8.0.19中，X协议对每种算法使用库默认压缩级别，客户端无法协商该默认压缩级别。从MySQL 8.0.20开始，客户端可以在协商期间为X协议连接请求特定的压缩级别。