MySQL-基础汇总
数据库对于任何一个从事后台开发的人说都是永远躲不掉的，任何系统或程序离开了数据的支持都变的毫无意义。而管理数据的工具——数据库就显得尤为重要。本章节我们的核心就是 MySQL，相信很多小伙伴跟我一样，也沉浸在增、删、改、查的舒适区里沾沾自喜。认为MySQL也不过如此，这不用起来也得心应手的嘛！而当你真正走出这个舒适圈，看看外面的世界（与他人技术交流亦或求职面试）。猛然发现自己真的是井底之蛙，有些概念或许听说过，有些甚至不知所云。所以有必要认真系统的去学习并整理一下 MySQL。
SQL的执行流程
众所周知，我们对 MySQL 数据库中数据的操作是通过执行 sql 语句来实现的。那么一个 sql 语句的执行中间经历了怎样的过程？
建立连接
无论我们的 sql 语句写的再天花乱坠，没有连上 MySQL 就是白费功夫。所以第一步得需要跟 MySQL数据库建立连接，客户端向 MySQL 数据库发送网络请求（TCP/IP、命名管道或共享内存、Unix域套接字这几种方式之一来与服务器进程建立连接。这几种连接方式了解下即可），每当有一个客户端进程连接到 MySQL 时，MySQL 都会创建一个线程来专门处理与这个客户端的交互，当该客户端退出时会与MySQL 断开连接，MySQL 并不会立即把与该客户端交互的线程销毁掉，而是把它缓存起来，在另一个新的客户端再进行连接时，为了节省线程销毁和创建的开销，把这个缓存的线程分配给这个新连接的客户端。那怎么知道相关线程的连接情况呢？(注：本文所有的命令执行都是通过Navicat执行的)
我们可以通过执行命令
show status like 'Threads%';
执行结果如下
- Threads_cached：表示线程缓存中的线程数量。MySQL会缓存一定数量的线程以应对新的连接请求，这样可以避免为每个新连接都创建和销毁线程的开销。如果这个数字接近
Threads_connected，那么说明线程缓存设置得比较合适。设置缓存大小的配置是thread_cache_size 默认大小为-1 可自动调整。它的最大值是16384。 - Threads_connected：当前打开的连接数。这个数字显示了有多少客户端正在与MySQL服务器进行交互。
- Threads_created：自服务器启动以来创建的线程总数。如果这个值越大，配置项 thread_cache_size 可相应的增大以提升线程的缓存命中率
- Threads_running：当前正在执行查询（运行）的线程数量。
这里提到了 thread_cache_size 我们可以通过命令进行查看
SELECT @@thread_cache_size
执行结果如下
-- 显示用户正在运行的线程
show FULL PROCESSLIST
关于连接其实还有一个需要关注的点——连接数，那要查看最大连接数我们可以通过执行
SELECT @@max_connections
执行结果如下
max_connections 表示最大的连接数，超过该值不允许建立连接 。 默认值是151，最小值是1最大值是100000。
想要查看连接超时时间可以通过执行命令
SELECT @@wait_timeout;
wait_timeout 非交互连接等待的时间 （单位s） 默认值28800 也就是8小 时，空闲的线程如果8小时没动静，则会断开。
在其他的连接的配置中比较重要的就是 Max_used_connections，查看与之相关的信息可以通过执行命令
show status like 'Max_used_connections%';
执行结果如下
Max_used_connections 自服务启动以来最大的连接数，它记录了自MySQL服务器启动以来，同一时刻并行连接数的最大值。这个值并不表示当前的连接数，而是提供了一个历史记录，用于评估MySQL服务器在过去所承受的最大连接压力。
Max_used_connections_time 表示达到这个峰值的时间。
在成功的与 MySQL 建立连接之后接下来就要开始进入查询的阶段了，因为我们发送给MySQL的请求是我们输入的sql语句（本质上是一段文本）所以首先要对sql 语句进行分析
解析sql
解析sql是借用解析器去把sql语句解析出来，看是否正确可分为 词法解析和语法解析
-
词法解析
顾名思义就是将 sql 语句打碎，转化成一个个的单词，判断单词是否正确
-
语法解析
在输入的sql语句中所有单词都正确的基础上检查该sql的语法是否正确。例如，where是不是写成where1,from写成from1. 表名、列名是否存在、用户是否有操作权限等等。 如果出现错误直接抛出错误。
通过解析器的解析，我们写的 sql 词法正确，语法上也没有错误。那接下来 MySQL 还要对 sql 语句进行预处理操作
预处理
在 MySQL 中，预处理（Prepared Statements）是一种通过编译和执行 SQL 语句的分离来优化性能和增强安全性的技术。预处理语句通常用于防止 SQL 注入攻击，并可以通过减少 SQL 语句的编译次数来提高性能。预处理语句是一种在 SQL 语句中包含占位符（通常是问号 ?）的语句。Mybatis 中拼接 sql 时用的 #{} 和 ${}，其中 #{} 就会去解析变成参数，然后进行预处理，能防止sql注入，并且必须传入参数。
查询优化
经过前面几个步骤的洗礼，我们的 sql 语句的所包含的信息完整且语法正确 (所查询的表、列、以及筛选条件都正确)，但是我们写的 sql 执行效率不是特别高，需要进行优化。此时优化器就登场了，它会对我们的 sql 语句进行优化（如外连接转化为内连接、表达式简化、子查询转为连接等等）在执行的时候还会判断需不需要走索引，总之优化器会先帮我们做这些工作。优化后会生成一个最终的执行计划，所以这个语句到底如何执行更好，优化器来决定。
到目前为止，我们还未真正的获取到数据。MySQL 把数据的存储和提取操作都封装到了存储引擎中。
存储引擎
执行器去根据表设置的存储引擎，调用不同存储引擎的API接口获取数据。如果要查看当前 MySQL的存储引擎可以通过执行命令
SHOW ENGINES; -- 查询当前服务器支持的存储引擎
执行结果如下
在以上存储引擎中常用的存储引擎就只有 InnoDB 和 MyISAM，其中 InnoDB 为默认的存储引擎。我们通过表格的形式来对比一下这两个存储引擎的区别。
| 对比 | 事务支持 | 外键支持 | 锁机制 | 计数统计 | 主键要求 |
|---|---|---|---|---|---|
| InnoDB | 支持 | 支持 | 支持行级锁 | 没有保存表的总行数 | 必须有主键 |
| MyISAM | 不支持 | 不支持 | 只支持表锁，不支持行锁和页面锁 | 保存有表的总行数 | 允许没有任何索引和主键的表存在 |
我们都知道数据最终是存到磁盘中的，不同的存储引擎会有自己的存储实现方式。那如何在磁盘里找到数据存储的位置，可以执行如下命令
SHOW VARIABLES LIKE '%datadir%';
结果如下
注：这里是安装的windows 版本的 MySQL, Linux 下的地址会有不同
为了体现不同存储引擎在磁盘中的存储方式不同，我们模拟创建两个存储引擎的表，执行如下命令
CREATE TABLE `t_teacher` (`id` int(10) NOT NULL COMMENT '主键id',`name` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '姓名',`age` int(5) DEFAULT NULL COMMENT '年龄',PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;CREATE TABLE `t_student` (`id` int(10) NOT NULL COMMENT '主键id',`name` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '姓名',`age` int(5) DEFAULT NULL COMMENT '年龄',PRIMARY KEY (`id`)
) ENGINE= MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
在上述 sql 片段中我们创建了两个表教师表和学生表，其中教师表采用默认的存储引擎 InnoDB，学生表用 MyISAM 我们来看这两个表在磁盘中的存储情况
从图上我们可以明显的看出 MyISAM的文件是3个，而InnoDB表数据文件只有1个。
MyISAM磁盘文件
- MYD文件 存储所有的数据记录
- MYI文件 存储索引信息，即表的索引数据
- sdi 系统数据文件，存储一些元数据、表结构，比如行数、空间碎片等
InnoDB磁盘文件
而 InnoDB 的磁盘文件就一个ibd文件存储数据与索引（关于Innodb的具体内容会单独整理一篇文章，此处不做具体的展开）
字符集与比较规则
与 sql执行流程相关的内容梳理完了，我们接下来看一块儿经常容易忽略的内容——字符集和比较规则。众所周知，我们创建数据库的时候都会有这样的选择项
字符集
字符集（Character Set），也被称为编码表，是一个系统支持的所有字符的集合。为了使计算机能够准确地表示、存储和处理各种文本数据，字符集定义了字符与二进制数据之间的映射关系。在计算机内部，所有的信息都是以二进制形式存储和处理的。字符集就是一套规则，它规定了如何将字符转换为二进制数据，以及如何将二进制数据转换回字符。我们看一下常见的字符集
| 字符集 | 特征 |
|---|---|
| ASCII | 共收录128个字符，包括空格、标点、数字、大小写字母及一些不可见字符 |
| ISO 8859-1 | 共收录256个字符是 ASCII 字符集的扩充，它的别名为 Latin1 |
| GB2312 | 收录汉字6763个，其他文字符号682个 |
| GBK | 是GB2312字符集的扩充，编码方式兼容GB2312 |
| UTF-8(重要) | 几乎收录了所有的字符，编码一个字符需要1~4字节 |
其他的字符集稍微了解下即可，我们还是把目光集中在重点的 UTF-8上
MySQL中的字符集
我们在创建数据库时会发现UTF-8字符集时有两个，utf8 与 utf8mb4。正如前面所说 UTF-8 字符集表示一个字符时需要14个字节，而正常情况下一般常用的字符用13个字节就够了，某些特殊的字符则需要1~4的字节来表示（比如表情 emoji）一个字符所用最大字节长度会在某些方面影响性能以及存储。所以我们在创建数据库时看到的 utf8 其实是一个 “简化” 的 UTF-8，它有一个别名叫 utf8mb3 它只使用1~3个字节。utf8mb4 才是正儿八经的 UTF-8 使用1~4个字节。在 MySQL8.0 以后已经将utf8mb4 认定为默认的字符集。那我们要看一下目前 MySQL中有哪些字符集，执行如下命令
show charset;
执行结果如下
Default collation 代表该字符集默认的比较规则，Maxlen则表示该字符集最多需要几个字节表示一个字符。
字符集比较规则
我们来看一下 UTF-8 系列的字符集有哪些比较规则，执行命令
SHOW COLLATION LIKE'utf8_%';
执行结果如下
那这么多的比较规则该如何进行选择呢，其实 Default 中 包含 yes的都是默认的比较规则。我们可以看到这些比较规则以 utf-8 开头而后面跟着的是比较规则对应的语言，比如 utf8mb4_polish_ci 表示波兰语比较规则，utf8mb4_spanish2_ci 是西班牙语比较规则。这些我们肯定大概率用不到仅作为一个了解，我们只需要知道 general_ci 结尾的是通用的比较规则就可以了。
附：比较规则后缀代表的含义
| 后缀 | 含义 |
|---|---|
| _ai | 不区分重音 |
| _as | 区分重音 |
| _ci | 不区分大小写 |
| _cs | 区分大小写 |
| _bin | 以二进制方式比较 |
总结
本篇是 MySQL 章节的开篇，内容不是很多。主要从sql执行流程的角度出发，在执行流程中涉及每个阶段一些 mysql 的信息查看，另外就是总结了下字符集和比较规则的一点冷知识，姑且算做一个开胃小菜。