从零开始学 Mysql – 连贯治理和存储引擎

前言

​ 本篇为集体 mysql 专栏的第二篇，第二篇将会是对于连贯治理以及存储引擎的探讨，以及 mysql 底层的交互过程，这个概念在之前的 mysql 专栏中有提到过，这里再一次进行总结，在第一篇开篇的时候探讨过这个专栏的内容大多数都是参考《从根上了解 Mysql》这本书，这里再次强调一遍，后续专栏文章不会再进行赘述。

概述

1. 客户端和服务端的连贯过程

   1. Tcp/ip 形式：重点为 IP 地址和端口
   2. 命名管道和共享内存：window 独有的连贯形式，然而没什么鸟用，不必理睬
   3. Unix 域套接字文件：如果服务端批改套接字的默认监听文件

2. mysql 申请解决流程

   1. 连贯治理：服务端接口客服端的查问 sql 语句
   2. 查问优化：次要工作为拆解命令并对命令进行“编译”
   3. 存储引擎：通过对外接口 API 接受命令并且查问数据

3. 存储引擎介绍

   1. 存储引擎介绍
   2. 批改存储引擎

Mysql 连贯

连贯形式

Tcp/IP

​ Tcp 是一种网络的通信协议，通常咱们只须要关注两个参数，IP 和端口 ，IP 地址能够看作门牌号，而端口能够看作应用程序的入口，进行网络通信须要 IP 和端口号能力实现，而端口号的范畴通常为0-65535，有了 IP 地址和端口之后咱们既能够进行 mysql 连贯了，日常应用中最常见的mysql -uroot -pxxx 命令，这一条命令的连贯形式理论就是一种 TCP/IP 的连贯形式。

​ Mysql 如果在装置过程不进行其余改变的状况下默认占用 3306 的端口，客户端中咱们连贯的时候能够通过 mysql -P3307 中的 -P 参数进行端口的指定，而服务端的启动则能够应用 mysqld -P3307 指定用其余的端口启动一个 mysql 的服务端服务，留神不要看花眼了，下面的参数客户端是 mysql 而服务端是mysqld。

集体比拟举荐端口的抉择上在软件默认的端口后面加个 1，比方 mysql 的默认端口 3306 举荐应用 13306，这样能够无效的躲避可能存在的和其余的应用程序的端口占用或者抵触，并且能够发现其实大多数的中间件或者框架都是应用 1 万以内的端口。

​

命名管道和共享内存

​ 这个形式次要针对 window 用户，客户端和服务端之间能够应用叫做命名管道或者共享内存的形式进行连贯，因为这个货色 不重要 所以简略理解即可，另外依据官网文档的介绍这种连接符形式要比 TCP/IP 的连贯形式快 30%-50%。

​ 命名管道：因为 Mysql 默认是不启用这个命名管道的形式的，须要在启动服务器程序的命令中加上 --enable-named-pipe 参数，而后在启动客户端程序的命令中退出 --pipe 或者 --protocol=pipe 参数，或者咱们在 my.ini 文件当中对于上面的内容进行批改：

MySQL 默认是不启用命名管道连贯形式，启用办法：[mysqld]
enable-named-pipe
socket=MySQL

​ 最初给出一个简略的 JAVA 例子理解如何配置链接即可，外围局部为：socketFactory=com.mysql.jdbc.NamedPipeSocketFactory：

public class MySQLNamedPipeTester {public static void main(String[] args) throws Exception {Class.forName("com.mysql.jdbc.Driver").newInstance();
        Connection conn = DriverManager.getConnection(
                "jdbc:mysql:///oschina?socketFactory=com.mysql.jdbc.NamedPipeSocketFactory",
                "root",
                "xxxx");
        PreparedStatement ps = conn.prepareStatement("SELECT COUNT(*) FROM xxxx");
        ResultSet rs = ps.executeQuery();
        while(rs.next()){System.out.println(rs.getInt(1));
        }
        //conn.close();}
}

​ 共享内存：共享内存的连贯形式 必须 保障客户端和服务端过程在同一个 Windows 主机，否则是无奈失效的，共享内存的形式是在启动服务器程序的命令中加上 --shared-memory 参数，并且进行重新启动之后即可，不过咱们也能够在客户端的命令当中退出相似--protocol=memory 参数来指定应用共享内存的形式通信。

Unix 域套接字文件

​ 不是很重要的货色，同样简略理解即可，这种连贯形式有点相似于本地的线程通信，因为古代操作系统少数都是从 UNIX 衍生进去的，所以这种连贯形式须要操作系统底层的通信反对，既然是本地线程通信那么天然须要保障客户端和服务端在同一个机器上。套接字连贯比拟罕用的场景比方咱们平时应用 localhost 连贯或者咱们指定 --protocol=socket 的启动参数，MySQL 服务器程序默认监听的 Unix 域套接字文件门路为 /tmp/mysql.sock ，同样客户端也会默认连贯这个套接字，如果咱们想要批改这种默认的连贯形式，咱们须要作出如下的调整：

​ 服务端：服务端在启动的时候能够指定mysqld --socket=/tmp/a.txt，这样默认监听的套接字文件就扭转了

​ 客户端：因为服务端扭转了监听的文件，所以客户端进行 UNIX 套接字文件连贯就须要应用在命令中加上 --socket=/temp/a.txt 的参数，例如mysql -hlocalhost -uroot --socket=/tmp/a.txt -p

再次强调一遍 mysqld 这个命令其实并不是罕用，这里仅仅作为演示命令应用形式

​

申请解决流程

​ 申请的解决逻辑从整体上看就是：客户端发送一段 sql 语句而后服务端依据 sql 语句获取后果文本返回给客户端。申请解决流程在书中感觉并不是非常直观，这里用以前画的一幅图作为比照解释，能够看到从整体上看整个 mysql 的连贯分为三个局部，第一部分为连贯治理，次要负责的是和客户端的申请交接，以及承受客户端发送过去的命令等等，第二局部为解析优化，次要是查看 sql 语句是否被执行过，以及进行语法的翻译操作和优化语句的命令，第三局部为存储引擎，也是 mysql 最外围的局部，存储引擎是最终进行数据查问中央，它会依据第二局部的命令去找到相干的数据而后返回给客户端，上面咱们分大节来一一解说他们的作用。

​

连贯治理

​ 连贯治理局部就是应用下面所说的连贯形式进行服务端和客户端的交互，通常状况下咱们会应用数据库连接池进行连贯，所以 mysql 会为每一个连贯的客户端调配一个线程进行交互，然而交互实现之后 并不是马上把线程销毁，通常要进行缓存并且留给下一个客户端连贯应用，这样就缩小了线程创立和调配以及销毁的开销。

​ 另外连贯治理局部通常也有诸多限度，比方须要用户名和明码进行认证，如果 mysql 不在同一台机器上也能够应用 SSL 的加密通信形式保障 mysql 连贯的平安。

解析优化

​ 解析优化的局部是 mysql 的重点，它蕴含了 查问缓存，词法剖析和查问优化 这三个局部。

查问缓存：

​ 查问缓存在 8.0 的版本中曾经删除了，在 mysql5.7 的版本中也曾经不举荐应用，至于起因大抵能够了解为古代的互联网资源不比以前，硬盘容量轻易用不说，内存也是轻易加，基本不差那点查问缓存的性能，然而重要起因根本还是 缓存命中率极低，比方上面的查问缓存命中的规定：

​ 1. 如果两个查问申请在任何字符上的不同(例如: 空格、正文、大小写)，都 会导致缓存不会命中。

​ 2. 如果应用了局部零碎函数，比方 now()，sum()等或者应用 mysql、information_schema、performance_schema 等零碎表的时候，即便语句和后果一摸一样，也是不走缓存的。

​ 3. 如果对于数据表进行过 CRUD 的操作，那么所有的缓存必须全副生效，并且将缓存立刻从高速缓存中删除

​ 能够发现单纯下面的两点根本能够让绝大多数的缓存生效古代的搜寻和查问多样化，导致查问缓存基本用不上，既然用不上那还保护它干啥，所以新版本根本也就不举荐应用并且在 8.0 版本间接删除了，

词法剖析：

​ 词法剖析就是从申请命令语句中提取“关键字”，并且拆分命令是插入还是删除还是查问等等，也能够了解为 mysql 在对于命令进行本人的“编译”操作。

查问优化：

​ 词法解析之后 mysql 就能够晓得咱们查问的是哪一张表，查问优化的工作是将咱们的查问命令依据 mysql 的一套规定进行优化，比方删除无意义的条件，简化查问语句等等，总之优化的目标就是进步查问的效率（大失所望，有时候会帮倒忙），在 mysql 中能够应用 explain 查看的语句的执行打算。

存储引擎

​ 存储引擎承受查问优化器优化之后的命令就开始干活了，所以存储引擎才是实在的数据存储模块管理者，负责记录表的存储地位，怎么把数据写入到物理硬盘上等等，然而具体的存储形式取决于存储器的数据结构设计。

小结

​ 通过下面的介绍之后，当初须要辨别 mysql 申请解决的概念概念，首先在宏观的层面上能够把 mysql 看作两个局部，第一个局部是从 连贯治理 - 查问优化 这一条链路，这一部分做的事件次要是承受申请并且解析和优化命令，然而实际上 并没有任何的数据操作 ，通常这部分划分到 Mysql Server 的局部。第二局部是 存储引擎 ，它才是真正干活的角色，次要负责数据的读取和存储，以及依据对外的接口进行理论的数据操作，最初这两个局部通过 对立的调度接口 进行关联，也就是说存储引擎须要实现特定的接口 API 接受命令的解析，优化实现的语句通过接口发送给存储引擎即可，这也意味着 Sever 其实并不需要关怀如何存储数据。

存储引擎介绍

​ mysql 的罕用的存储引擎蕴含上面的局部，其实个别罕用的也就 MERMORY，MyISaM，InnoDB 这三个。

​ 上面是存储引擎对于非凡性能的反对状况，当然也是简略理解即可

查看以后零碎反对的存储引擎

命令：SHOW ENGINES;

参数解释：

​ Support：存储引擎是否可用

​ DEFAULT：以后服务器默认的存储引擎，能够看到是 InnoDB

​ Comment：存储的引擎的形容，应该不难懂

​ Transactions：是否反对事务

​ XA：是否反对分布式事务

Savepoints：是否反对 局部事务 回滚

批改存储引擎

​ 一条语句：ALTER TABLE 表名 ENGINE = 存储引擎名称;

​ 上面间接用书上的案例进行成果演示：

 mysql> ALTER TABLE engine_demo_table ENGINE = InnoDB;
    Query OK, 0 rows affected (0.05 sec)
    Records: 0  Duplicates: 0  Warnings: 0
mysql>
 
 mysql> SHOW CREATE TABLE engine_demo_table\G

  *************************** 1. row ***************************

Table: engine_demo_table

  Create Table: CREATE TABLE `engine_demo_table` (`i` int(11) DEFAULT NULL

  ) ENGINE=InnoDB DEFAULT CHARSET=utf8

  1 row in set (0.01 sec)

mysql>

总结

​ 到此书中的第一篇内容算是讲述完了，能够看到第一章节的内容都是十分通俗的内容，后续的难度会逐步增强。本文的的重点局部毫无疑问就是申请的解决流程局部，特地是 存储引擎，在后续的很多内容解说都是围绕存储引擎 Inn DB 进行介绍的，咱们学习 Mysql 的深刻内容同样如此。

写到最初

​ 再次回顾一遍发现内容还是比较简单的，如果感觉有帮忙无妨点个赞？