参考学习资料：极客时间 MySQL实战45讲（丁奇）

⚡1.基础架构：一条查询语句是如何执行的

​ MySQL可以分为 server层和存储引擎层。

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

​ 存储引擎负责数据的存储和提取。默认使用innodb，在建表时可以自行选择

一、MySQL体系结构

• 连接层：是一些客户端和链接服务，包含本地sock 通信和大多数基于客户端/服务端工具实现的类似于 TCP/IP的通信
• 服务层：大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部 分内置函数的执行
• 引擎层：负责了MySQL中数据的存储和提取，服务器通过API和存储引擎进行通 信，其中索引 存储在该层中
• 存储层：主要是将数据(如: redolog、undolog、数据、索引、二进制日志、错误日志、查询 日志、慢查询日志等)存储在文件系统之上，并完成与存储引擎的交互

​ 需求：先从数据库中读取摸一个字段的值，然后在该字段上的基础上进行修改，由于操作不是原子性，无法保证线程安全，也就是当A线程读取到1时，想+1，赋值为2。而B线程已经将数据修改为2了，那么A线程应该是在2的基础上+1，赋值为3。但实际中可能该值都到8了，A又给人家改回2了。所以我们该如何解决数据安全问题？

1. 本能想到利用JVM层面的锁机制，保证每次只有一个线程进行操作，但这个性能太差，而且JVM锁无法在分布式中生效。
2. 利用数据库事务操作，下文我们主要讲Mysql事务的知识。

宝塔中安装MySQL

（1）宝塔面板的系统防火墙放行3306端口

（2）云服务器的防火墙放行3306端口

（3）软件商店搜索并安装MySQL

（4）修改数据库密码

（5）使用命令行工具连接服务器，使用命令mysql -uroot -p 连接数据库

（6）使用命令新建一个用户

# 创建一个用户
create user '用户名'@'%' identified with mysql_native_password by '密码';

# 例如：
create user 'dogusers'@'%' identified with mysql_native_password by '111111111';

# 或者使用下面这条创建用户
create user '用户名'@'%' identified by '密码' with grant option;

[TOC]

参考资料：《MySQL是怎么运行的：从根儿上理解MySQL》。

我们前边详细、详细又详细的唠叨了 InnoDB 存储引擎的 B+ 树索引，我们必须熟悉下边这些结论：

• 每个索引都对应一棵 B+ 树， B+ 树分为好多层，最下边一层是叶子节点，其余的是内节点。所有 用户记录都存储在 B+ 树的叶子节点，所有 目录项记录 都存储在内节点。
• InnoDB 存储引擎会自动为主键（如果没有它会自动帮我们添加）建立 聚簇索引 ，聚簇索引的叶子节点包含完整的用户记录。
• 我们可以为自己感兴趣的列建立 二级索引 ， 二级索引 的叶子节点包含的用户记录由 索引列 + 主键 组成，所以如果想通过 二级索引 来查找完整的用户记录的话，需要通过 回表 操作，也就是在通过 二级索引找到主键值之后再到 聚簇索引 中查找完整的用户记录。
• B+ 树中每层节点都是按照索引列值从小到大的顺序排序而组成了双向链表，而且每个页内的记录（不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单链表。如果是 联合索引 的话，则页面和记录先按照 联合索引 前边的列排序，如果该列值相同，再按照联合索引 后边的列排序。
• 通过索引查找记录是从 B+ 树的根节点开始，一层一层向下搜索。由于每个页面都按照索引列的值建立了Page Directory （页目录），所以在这些页面中的查找非常快。

参考资料：《MySQL是怎么运行的：从根儿上理解MySQL》。

数据页结构的快速浏览

数据页代表的这块 16KB 大小的存储空间可以被划分为多个部分，不同部分有不同的功能，各个部分如图所示：

从图中可以看出，一个 InnoDB 数据页的存储空间大致被划分成了 7 个部分，有的部分占用的字节数是确定的，有的部分占用的字节数是不确定的。下边我们用表格的方式来大致描述一下这7个部分都存储一些啥内容（快速的瞅一眼就行了）：

参考资料：《MySQL是怎么运行的：从根儿上理解MySQL》。

前言：

我们一般使用的MySQL关系型数据库，更是经典中的经典，虽说MySQL已经非常成熟，但对于MySQL的掌握程度，如果我们只停留在使用层面，不了解它的底层设计，那咱永远只能停留在写SQL上，成为一个彻头彻尾的CRUDBoy。

一：InnoDB页简介

InnoDB 是一个将表中的数据存储到磁盘上的存储引擎，所以即使关机后重启我们的数据还是存在的。而真正处理数据的过程是发生在内存中的，所以需要把磁盘中的数据加载到内存中，如果是处理写入或修改请求的话，还需要把内存中的内容刷新到磁盘上。而我们知道读写磁盘的速度非常慢，和内存读写差了几个数量级，所以当我们想从表中获取某些记录时， InnoDB 存储引擎需要一条一条的把记录从磁盘上读出来么？不，那样会慢死，InnoDB 采取的方式是：将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位，InnoDB中页的大小一般为 16 KB。也就是在一般情况下，一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中的16KB内容刷新到磁盘中。

[TOC]

参考资料：《MySQL是怎么运行的：从根儿上理解MySQL》。

一、前言——没有索引的查找

在正式介绍 索引 之前，我们需要了解一下没有索引的时候是怎么查找记录的。我们下边先只唠叨搜索条件为对某个列精确匹配的情况，所谓精确匹配，就是搜索条件中用等于 = 连接起的表达式，比如这样：

SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;

[TOC]

参考资料：《MySQL是怎么运行的：从根儿上理解MySQL》。

一、前言——缓存的重要性

对于使用 InnoDB 作为存储引擎的表来说，不管是用于存储用户数据的索引（包括聚簇索引和二级索引），还是各种系统数据，都是以 页 的形式存放在 表空间 中的，而所谓的 表空间 只不过是InnoDB 对文件系统上一个或几个实际文件的抽象，也就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道，磁盘的速度慢的跟乌龟一样，怎么能配得上“快如风，疾如电”的 CPU 呢？所以 InnoDB 存储引擎在处理客户端的请求时，当需要访问某个页的数据时，就会把完整的页的数据全部加载到内存中，也就是说即使我们只需要访问一个页的一条记录，那也需要先把整个页的数据加载到内存中。将整个页加载到内存中后就可以进行读写访问了，在进行完读写访问之后并不着急把该页对应的内存空间释放掉，而是将其 缓存 起来，这样将来有请求再次访问该页面时，就可以省去磁盘 IO 的开销了。

[TOC]

前言

搞数据库一个避不开的概念就是 Join ，翻译成中文就是 连接 。相信很多小伙伴在初学连接的时候有些一脸懵逼，理解了连接的语义之后又可能不明白各个表中的记录到底是怎么连起来的，以至于在使用的时候常常陷入下边两种误区：

• 业务至上，管他三七二十一，再复杂的查询也用在一个连接语句中搞定。
• 敬而远之，上次 的慢查询就是因为使用了连接导致的，以后再也不敢用了。

我们先建立两个简单的表并给它们填充一点数据：