Mysql官网

mysql安装教程

Navicat免费安装亲测有用

简介

大体来说，MySQL 服务端可以分为 Server 层和存储引擎层两部分。Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

而存储引擎层负责数据的存储和检索。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL5.5.5 版本开始成为了默认存储引擎。也就是说，你执行 create table 建表的时候，如果不指定引擎类型，默认使用的就是InnoDB。不过，你也可以通过指定存储引擎的类型来选择别的引擎，比如在 create table语句中使用 engine=memory,来指定使用内存引擎创建表。

具体流程如下：

1. 当客户端的 SQL 发送到 MySQL 时，首先是到达 Server 层的连接器，连接器会对你此次发起的连接进行权限校验，以此来获取你这个账号拥有的权限。当你的账号或密码不正确时，会报 Access denied for user 错误，相信大家对这个错误也并不陌生。连接成功如果后续没有任何操作，那么这个连接就处于空闲状态，到达一定时间后它便会断开连接，这个时间一般是 8 小时，是由 wait_timeout 参数控制的。

2. 查询缓存（在 MySQL 8.0 之后就被砍了）具体做法就是将一个查询语句作为 key，将上一次请求的结果作为 value，存储在缓存组件中，当同样的语句来查询的时候即可立马返回结果，不需要经历词法、语法分析等以下的步骤。只要表有数据改动缓存就失效了，在我们常见的联机事务处理（OLTP）场景下是个鸡肋。

3. 接下来就到了分析器来进行语法分析、词法分析。MySQL 会首先对你的语句进行“词法分析”，来判断你的语句是什么类型以及携带什么参数等。比如：MySQL 会将输入语句的 select 提取出来，判断出这是一条查询语句、将 from 后面的 user 提取出来作为查询的表名、把 id 提取出来作为列名等。做完这些 MySQL 将会进行“语法分析”来判断你的语句的语法是否有误、是否满足 MySQL 的语法。如果语法有问题，那这个错误相信大家都不陌生：You have an error in your SQL syntax; check the manual……

4. 经过分析器就到了优化器，它会对你的语句进行优化判断。比如你的表中有多个索引，优化器会帮你选择使用哪个索引、你使用了 join 多表连接，优化器会帮你调整表的连接顺序。我们平日里用的 explain 其实就是让 MySQL 告诉我们它的优化决定策略是怎样的。
   优化器怎么选择执行计划

5. 最后会到达执行器，它先会判断你对这个 user 表是否有权限查询，如果没有权限它将会拒绝本次查询，返回错误信息。如果有权限，它将会根据表的存储引擎提供的接口进行数据查询将重复遍历表的行数据，判断 id 字段是否等于 1。直到遍历完整个表将符合条件的数据作为结果集返回给客户端(连接工具（Navacat、SQLyog、JDBC）都归纳为MySQL客户端(Client)，主要用于发送执行sql语句的请求)。

Server 层

• 负责处理 SQL 语句、解析、优化、缓存等。
• 负责权限管理、用户认证等。 提供了各种 SQL 函数和存储过程。
• 提供了复制、备份、恢复等高级功能。
• Server 层有自己的日志系统，称为 binlog（归档日志）。binlog 记录了所有修改数据库数据的 SQL语句（如INSERT、UPDATE、DELETE 等）的信息，但不包括 SELECT 和 SHOW 这类查询语句。binlog主要用于复制和恢复操作。

binlog,redo log, undolog 区别

连接器

第一步，你会先连接到这个数据库上，这时候接待你的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是这么写的：

mysql -h$ip -P$port -u$user -p

输完命令之后，你就需要在交互对话里面输入密码。
连接命令中的 mysql 是客户端工具，用来跟服务端建立连接。在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。

• 如果用户名或密码不对，你就会收到一个"Access denied for user"的错误，然后客户端程序结束执行。
• 如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。
  

客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout控制的，默认值是 8 小时。如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。

 # 查看数据库的连接状态show processlist;#查看当前的wait_timeout参数值SHOW VARIABLES LIKE 'wait_timeout';

注意：建立连接的过程通常是比较复杂的，建议在使用中要尽量减少建立连接的动作，尽量使用长连接。为了提升数据库并发性，可以建立一个数据库连接池。

长连接：连接成功后，如果客户端持续有请求，则一直使用同一个连接。
短连接：每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。

连接器常见的问题：
全部使用长连接后，有时候 MySQL 占用内存涨得特别快，因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的，这些资源会在连接断开的时候才释放，所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM）。从现象看就是 MySQL 异常重启了

解决方案：

• 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再 重连。
• MySQL 5.7 以上版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

在Java 中与 MySQL 数据库交互通常使用 JDBC (Java Database Connectivity) API，它提供了自己的连接管理和错误处理机制。请注意，频繁地创建和关闭连接可能会对性能产生负面影响，特别是在高负载的情况下。因此，在生产环境中，通常会使用连接池来管理数据库连接，这样可以复用现有的连接而不是频繁地创建和销毁它们

查询缓存

在MySQL5.7版本，连接完成后就会直接查询缓存，查询此语句是否执行过。执行逻辑就会来到第二步：查询缓存。

MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句。及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个value 就会被直接返回给客户端。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

注意，MySQL 8.0 版本直接将查询缓存的整块功能删掉了。
MySQL 为什么在 8.0 版本中移除了查询缓存功能

分析器

若查询缓存未命中，则会执行分析器，来分析查询语句是否合法。
分析器先会做“词法分析”。MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“user”识别成“表名 user”，把字符串“id”识别成“列 id”。

词法分析：

• 主要负责从 SQL 语句中提取关键字，比如：查询的表，字段名，查询条件等等。
• 词法分析阶段是从 information_schema 里面获得table表的结构信息的
  
  做完了这些识别以后，就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。

语法分析：

• 判断输入的SQL 语句是否满足 MySQL 语法
• 如果 SQL 语句不对，就会返回 You have an error in your SQL syntax的错误提醒，一般语法错误会提示第一个 出现错误的位置，所以你要关注的是紧接“use near”的内容
  

优化器

经过了分析器，若语句正确，就会进入优化器。优化器的作用是在基于同一个查询语句的多个查询方案中找出效率最高的。比如，在表里面有多个索引的时候，决定使用哪个索引；在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

这里如果优化器发现语句用了联合索引但是不符合最左前缀，会自动补齐在
如何选择执行计划

执行器

执行器根据优化器生成的计划执行操作，同时与存储引擎协作，但不直接负责数据存储

当执行器需要执行一个SQL语句时，它会通过Handler接口调用存储引擎的方法，如read_row()读取数据、update_row()更新数据等。存储引擎根据自身特性实现这些方法，完成具体的数据操作后，将结果返回给执行器。这种协作机制使得MySQL能够灵活地支持多种存储引擎。

开始执行的时候，要先判断一下你对这个表有没有执行查询的权限，如果没有，就会返回没有权限的错误。如果有权限，就打开表继续执行。这是一种安全机制，确保只有被授权的用户才能访问和操作数据。

注意：

• 如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。
• 在语法分析过程中，解析器会进行一些初步的权限检查 precheck，例如验证用户是否有权访问指定的数据库和 表。
• 有些时候，SQL语句要操作的表不只是SQL字面上那些。SQL执行过程中可能会有触发器这种在运行时才能确定的过程，precheck是不能对这种运行时涉及到的表进行权限校验的，所以需要在执行器阶段进行权限检查。

打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口：

1.调用引擎接口取这个表的第一行，判断是否满足条件，如果不是则跳过，如果是则将这行存在结果集中
2.调用引擎接口取下一行，重复相同的判断逻辑，直到取到这个表的最后一行
3.执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端

至此，这个语句就执行完成了

存储引擎层

• 负责数据的存储和检索。
• MySQL 支持多种存储引擎，如 InnoDB、MyISAM、Memory 等，每种引擎都有其特点和适用场景。
• InnoDB 是 MySQL 的默认存储引擎，它支持事务、行级锁定和外键约束。InnoDB 有自己的日志系统，称 为 redo log（重做日志） 和 undo log（撤销日志）。redo log 用于保证事务的持久性，在数据库崩溃后可以用来恢复数据；undo log 用于支持事务的原子性和多版本并发控制（MVCC）。

更新语句是怎么执行的

如果是走update的流程，在查询缓存的流程上，在一个表上有更新的时候，跟这个表有关的查询缓存会失效，会把所有缓存结果都清空。这也就是我们一般不建议使用查询缓存的原因

更新涉及到了redo和undo log，这是在执行引擎做的

例子

mysql> update T set c=c+1 where ID=2;

1.执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2.执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3.引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时redo log 处于 prepare 状态。
然后告知执行器执行完成了，随时可以提交事务。
4.执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
5.执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

日志

redo log

MySQL 里经常说到的 WAL 技术（预写式日志），WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写

write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos 和 checkpoint 之间的是空着的部分，可以用来记录新的操作。如果 write pos 追上checkpoint，表示满了，这时候不能再执行新的更新，刷到磁盘，然后把checkpoint推进一下。

有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

下图时候存储文件夹的位置

binlog

在server层的
这两种日志有以下三点不同。

1.redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2.redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻
辑，比如“给 ID=2 这一行的 c 字段加 1 ”。redo log 是从数据页的角度来看的，它关心的是数据在磁盘上的物理布局和如何高效地修改这些数据。binlog 是从 SQL 语句的角度来看的，它关心的是执行了哪些操作以及这些操作的内容。
3.redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指binlog 文件写到一定大小后会切
换到下一个，并不会覆盖以前的日志

日志	binlog	redo log	undo log
作用层级	Server层	InnoDB存储引擎层	InnoDB存储引擎层
作用	支持备份恢复和主从复制，记录所有数据变更操作。	保证事务的持久性（Crash-Safe），支持故障恢复。	支持事务的原子性和多版本并发控制（MVCC）。
记录内容	记录逻辑操作（如 SQL 语句或行数据的变化）	记录物理修改（数据页的具体更改）	记录事务修改前的数据，用于回滚和 MVCC
写入方式	追加写入：文件写满后创建新文件，不覆盖旧日志。	循环写入：固定大小，写满后从头开始覆盖。	随事务变化按需生成，形成版本链。
主要用途	数据恢复到指定时间点；主从复制同步。	宕机后恢复已提交的事务，保证数据一致性。	支持事务回滚；基于 MVCC 实现快照读和隔离性。

mysql事务的二段提交

二段提交