MySQL学习笔记之基础篇
MySQL基础篇
DDL(数据定义语言)
1. 作用:
用来定义数据库对象(数据库、表、字段)
2. 数据库操作
① 查询所有数据库
1 | SHOW DATABASES; |
② 查询当前数据库:
1 | SELECT DATABASE(); |
③ 创建数据库:
1 | CREATE DATABASE [ IF NOT EXISTS ] 数据库名 [ DEFAULT CHARSET 字符集] [COLLATE 排序规则 ]; |
④ 删除数据库:
1 | DROP DATABASE [ IF EXISTS ] 数据库名; |
⑤ 使用数据库:
1 | USE 数据库名; |
注意:UTF8字符集长度为3字节,有些符号占4字节,所以推荐用utf8mb4字符集
3. 表操作
(1) 查询当前数据库所有表:
1 | SHOW TABLES; |
(2) 查询表结构:
1 | DESC 表名; |
(3) 查询指定表的建表语句:
1 | SHOW CREATE TABLE 表名; |
(4) 创建表:
1 | CREATE TABLE 表名( |
注意:最后一个字段后面没有逗号
(5) 添加字段:
1 | ALTER TABLE 表名 ADD 字段名 类型(长度) [COMMENT 注释] [约束]; |
例:ALTER TABLE emp ADD nickname varchar(20) COMMENT '昵称';
(6) 修改数据类型:
1 | ALTER TABLE 表名 MODIFY 字段名 新数据类型(长度); |
(7) 修改字段名和字段类型:
1 | ALTER TABLE 表名 CHANGE 旧字段名 新字段名 类型(长度) [COMMENT 注释] [约束]; |
例:将emp表的nickname字段修改为username,类型为varchar(30)
ALTER TABLE emp CHANGE nickname username varchar(30) COMMENT '昵称';
(8) 删除字段:
1 | ALTER TABLE 表名 DROP 字段名; |
(9) 修改表名:
1 | ALTER TABLE 表名 RENAME TO 新表名 |
(10) 删除表:
1 | DROP TABLE [IF EXISTS] 表名; |
4. 数据类型
(1) 数值类型
用于存储数字,分整数、浮点、定点数:
① 整数类型(按范围从小到大)
| 类型 | 大小 | 有符号范围 | 无符号范围 | 说明 |
|---|---|---|---|---|
| TINYINT | 1byte | (-128, 127) | (0, 255) | 小整数 |
| SMALLINT | 2bytes | (-32768, 32767) | (0, 65535) | 中整数 |
| MEDIUMINT | 3bytes | (-8388608, 8388607) | (0, 16777215) | 大整数 |
| INT/INTEGER | 4bytes | (-2147483648, 2147483647) | (0, 4294967295) | 常用大整数 |
| BIGINT | 8bytes | (-2^63, 2^63-1) | (0, 2^64-1) | 极大整数 |
✅ 备注:无符号整数写法(如无符号 int):INT UNSIGNED
② 浮点 / 定点数
| 类型 | 大小 | 说明 |
|---|---|---|
| FLOAT | 4bytes | 单精度浮点(范围约 ±3.4E+38) |
| DOUBLE | 8bytes | 双精度浮点(范围约 ±1.8E+308) |
| DECIMAL | 依赖 M/D | 精确定点数(适合金额等场景) |
✅ 备注:double 可指定 “总长 + 小数位”,格式:double(总长, 小数位)(如double(4,1))
(2) 字符类型
用于存储字符串 / 二进制数据,分定长、变长、二进制、文本:
| 类型 | 大小范围 | 描述 |
|---|---|---|
| CHAR | 0-255bytes | 定长字符串(性能高) |
| VARCHAR | 0-65535bytes | 变长字符串(性能略低) |
| TINYBLOB | 0-255bytes | 小二进制数据(≤255 字符) |
| TINYTEXT | 0-255bytes | 短文本字符串 |
| BLOB | 0-65535bytes | 长二进制数据 |
| TEXT | 0-65535bytes | 长文本数据 |
| MEDIUMBLOB | 0-16777215bytes | 中等长二进制数据 |
| MEDIUMTEXT | 0-16777215bytes | 中等长文本数据 |
| LONGBLOB | 0-4294967295bytes | 极大二进制数据 |
| LONGTEXT | 0-4294967295bytes | 极大文本数据 |
✅ 性能提示:同长度下,char(n)(如char(10))性能优于varchar(n)(定长存储更高效)
(3) 日期时间类型
用于存储日期、时间相关数据:
| 类型 | 大小 | 范围 | 格式 | 描述 |
|---|---|---|---|---|
| DATE | 3bytes | 1000-01-01 ~ 9999-12-31 | YYYY-MM-DD | 纯日期值 |
| TIME | 3bytes | -838:59:59 ~ 838:59:59 | HH:MM:SS | 时间间隔 / 持续时间 |
| YEAR | 1byte | 1901 ~ 2155 | YYYY | 纯年份值 |
| DATETIME | 8bytes | 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 | YYYY-MM-DD HH:MM:SS | 混合日期 + 时间 |
| TIMESTAMP | 4bytes | 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07 | YYYY-MM-DD HH:MM:SS | 带时间戳特性的日期时间 |
DML(数据操作语言)
1. 添加数据
(1) 指定字段:
1 | INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...); |
(2) 全部字段:
1 | INSERT INTO 表名 VALUES (值1, 值2, ...); |
(3) 批量添加数据:
1 | INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...), (值1, 值2, ...), (值1, 值2, ...); |
注意:
- 字符串和日期类型数据应该包含在引号中
- 插入的数据大小应该在字段的规定范围内
2. 更新和删除数据
(1) 修改数据:
1 | UPDATE 表名 SET 字段名1 = 值1, 字段名2 = 值2, ... [ WHERE 条件 ]; |
(2) 删除数据:
1 | DELETE FROM 表名 [ WHERE 条件 ]; |
DQL(数据查询语言)
1. 语法:
1 | SELECT |
2. 基础查询
(1) 查询多个字段:
1 | SELECT 字段1, 字段2, 字段3, ... FROM 表名; |
(2) 设置别名:
1 | SELECT 字段1 [ AS 别名1 ], 字段2 [ AS 别名2 ], 字段3 [ AS 别名3 ], ... FROM 表名; |
(3) 去除重复记录:
1 | SELECT DISTINCT 字段列表 FROM 表名; |
3. 条件查询
(1) 语法:
1 | SELECT 字段列表 FROM 表名 WHERE 条件列表; |
(2) 条件:
| 比较运算符 | 功能 |
|---|---|
| > | 大于 |
| >= | 大于等于 |
| < | 小于 |
| <= | 小于等于 |
| = | 等于 |
| <> 或 != | 不等于 |
| BETWEEN … AND … | 在某个范围内(含最小、最大值) |
| IN(…) | 在in之后的列表中的值,多选一 |
| LIKE 占位符 | 模糊匹配(_匹配单个字符,%匹配任意个字符) |
| IS NULL | 是NULL |
| 逻辑运算符 | 功能 |
|---|---|
| AND 或 && | 并且(多个条件同时成立) |
| OR 或 || | 或者(多个条件任意一个成立) |
| NOT 或 ! | 非,不是 |
(3) 例子:
1 | -- 1. 查询年龄等于 88 的员工 |
注意:MySQL 中查询 idCard 为 NULL 的员工时,不能用 idCard = null 或 idCard == null,在 MySQL 中,NULL表示「未知值」,不是一个具体的数值 / 字符串,因此普通的比较运算符(=、==、!=、<>)无法和 NULL 进行有效比较—— 用这些运算符和 NULL 比较的结果既不是TRUE也不是FALSE,而是NULL(不成立),最终查不到任何数据。
4. 聚合查询(聚合函数)
(1) 常见聚合函数:
| 函数 | 功能 |
|---|---|
| count | 统计数量 |
| max | 最大值 |
| min | 最小值 |
| avg | 平均值 |
| sum | 求和 |
(2) 语法:
1 | SELECT 聚合函数(字段列表) FROM 表名; |
(3) 代码示例:
1 | -- 1.统计该企业员工数量 |
注意:null 值不参与所有聚合函数运算
关键逻辑:count(\*)
统计所有符合条件的行数(不管字段是否为 NULL),只要这一行存在,就会被计数,适合直接统计 “员工总数”。
5. 分组查询
(1) 语法:
1 | SELECT 字段列表 FROM 表名 [ WHERE 条件 ] GROUP BY 分组字段名 [ HAVING 分组后的过滤条件 ]; |
(2) where 和 having 的区别:
- 执行时机不同:where是分组之前进行过滤,不满足where条件不参与分组;having是分组后对结果进行过滤。
- 判断条件不同:where不能对聚合函数进行判断,而having可以。
(3) 代码示例:
1 | -- 1.根据性别分组,统计男性员工和女性员工的数量 |
关键逻辑:
① HAVING COUNT(*) >= 3
分组后的筛选:只保留 “统计人数 ≥ 3” 的分组 —— 比如西安分组只有 2 人,就会被筛掉;北京有 6 人、上海 4 人、江苏 3 人,都会保留。
→ 记住:HAVING只管 “分组后的统计结果”(比如 COUNT (*)),不管 “单个员工的字段”。
② SELECT workaddress,count(*)
最终展示:把筛选后的分组结果展示出来,列是 “工作地址” 和 “对应人数”。
(4) 注意事项
- 执行顺序:where > 聚合函数 > having,因为
WHERE先筛行→GROUP BY分组→聚合函数统计→HAVING筛组 - 分组之后,查询的字段一般为聚合函数和分组字段,查询其他字段无任何意义(上述例子中,workaddress 是 分组标识,count(*) 是聚合函数)
6. 排序查询
(1) 语法:
1 | SELECT 字段列表 FROM 表名 ORDER BY 字段1 排序方式1, 字段2 排序方式2; |
(2) 排序方式:
- ASC: 升序(默认)
- DESC: 降序
(3) 代码示例:
1 | -- 1.根据年龄对公司的员工进行升序排序 |
(4) 注意:如果是多字段排序,当第一个字段值相同时,才会根据第二个字段进行排序
7. 分页查询
(1) 语法:
1 | SELECT 字段列表 FROM 表名 LIMIT 起始索引, 查询记录数; |
(2) 注意:
- 起始索引从0开始,起始索引 = (查询页码 - 1) * 每页显示记录数
- 分页查询是数据库的方言,不同数据库有不同实现,MySQL是LIMIT
- 如果查询的是第一页数据,起始索引可以省略,直接简写 LIMIT 10
(3) 代码示例:
1 | -- 1.查询第1页员工数据,每页展示10条记录 |
8. 综合练习
1 | -- 1.查询年龄为20,21,22,23岁的女性员工信息 |
9. DQL 编写顺序
1 | 1. FROM → 2. WHERE → 3. GROUP BY → 4. HAVING → 5. ORDER BY → 6. LIMIT |
10. DQL执行顺序
FROM -> WHERE -> GROUP BY、HAVING -> SELECT -> ORDER BY -> LIMIT
DCL
1. 管理用户
(1) 查询用户:
1 | USE mysql; |
(2) 创建用户:
1 | CREATE USER '用户名'@'主机名' IDENTIFIED BY '密码'; |
(3) 修改用户密码:
1 | ALTER USER '用户名'@'主机名' IDENTIFIED WITH mysql_native_password BY '新密码'; |
(4) 删除用户:
1 | DROP USER '用户名'@'主机名'; |
(5) 代码示例:
1 | -- 创建用户test,只能在当前主机localhost访问 |
2. 权限控制
(1) 常用权限:
| 权限 | 说明 |
|---|---|
| ALL, ALL PRIVILEGES | 所有权限 |
| SELECT | 查询数据 |
| INSERT | 插入数据 |
| UPDATE | 修改数据 |
| DELETE | 删除数据 |
| ALTER | 修改表 |
| DROP | 删除数据库/表/视图 |
| CREATE | 创建数据库/表 |
(2) 查询权限:
1 | SHOW GRANTS FOR '用户名'@'主机名'; |
(3) 授予权限:
1 | GRANT 权限列表 ON 数据库名.表名 TO '用户名'@'主机名'; |
(4) 撤销权限:
1 | REVOKE 权限列表 ON 数据库名.表名 FROM '用户名'@'主机名'; |
(5) 注意事项
- 多个权限用逗号分隔
- 授权时,数据库名和表名可以用 * 进行通配,代表所有
实用技巧
1. DataGrip 快速执行单行 SQL 的方法
使用 Ctrl+Enter(Windows/Linux),无需选中整行,只需将光标定位在目标行,按下此快捷键,DataGrip 会自动执行该行完整 SQL 语句。
2. 换行技巧(无需移到行尾)
Windows/Linux:Shift + Enter
3. 单行注释(最常用)
用 --(两个减号)开头,后面跟注释内容,注释范围从--到行尾。
1 | -- 这是单行注释(整行注释) |
函数
- 字符串函数
- 数值函数
- 日期函数
- 流程函数
1. 字符串函数
(1) 常用函数:
| 函数 | 功能 |
|---|---|
| CONCAT(s1, s2, …, sn) | 字符串拼接,将s1, s2, …, sn拼接成一个字符串 |
| LOWER(str) | 将字符串全部转为小写 |
| UPPER(str) | 将字符串全部转为大写 |
| LPAD(str, n, pad) | 左填充,用字符串pad对str的左边进行填充,达到n个字符串长度 |
| RPAD(str, n, pad) | 右填充,用字符串pad对str的右边进行填充,达到n个字符串长度 |
| TRIM(str) | 去掉字符串头部和尾部的空格 |
| SUBSTRING(str, start, len) | 返回从字符串str从start位置起的len个长度的字符串 |
| REPLACE(column, source, replace) | 替换字符串 |
(2) 使用示例:
1 | select concat('Hello','MySQL'); |
2. 数值函数
(1) 常见函数:
| 函数 | 功能 |
|---|---|
| CEIL(x) | 向上取整 |
| FLOOR(x) | 向下取整 |
| MOD(x, y) | 返回x/y的模 |
| RAND() | 返回0~1内的随机数 |
| ROUND(x, y) | 求参数x的四舍五入值,保留y位小数 |
(2) 代码示例:
1 | select ceil(1.5); |
3. 日期函数
(1) 常用函数:
| 函数 | 功能 |
|---|---|
| CURDATE() | 返回当前日期 |
| CURTIME() | 返回当前时间 |
| NOW() | 返回当前日期和时间 |
| YEAR(date) | 获取指定date的年份 |
| MONTH(date) | 获取指定date的月份 |
| DAY(date) | 获取指定date的日期 |
| DATE_ADD(date, INTERVAL expr type) | 返回一个日期/时间值加上一个时间间隔expr后的时间值 |
| DATEDIFF(date1, date2) | 返回起始时间date1和结束时间date2之间的天数 |
(2) 代码示例:
1 | select curdate(); |
4. 流程函数
(1) 常用函数:
| 函数 | 功能 |
|---|---|
| IF(value, t, f) | 如果value为true,则返回t,否则返回f |
| IFNULL(value1, value2) | 如果value1不为空,返回value1,否则返回value2 |
| CASE WHEN [ val1 ] THEN [ res1 ] … ELSE [ default ] END | 如果val1为true,返回res1,… 否则返回default默认值 |
| CASE [ expr ] WHEN [ val1 ] THEN [ res1 ] … ELSE [ default ] END | 如果expr的值等于val1,返回res1,… 否则返回default默认值 |
(2) 代码示例:
1 | select if(true,'OK','Error'); |
1 | select |
约束
1. 分类:
| 约束 | 描述 | 关键字 |
|---|---|---|
| 非空约束 | 限制该字段的数据不能为null | NOT NULL |
| 唯一约束 | 保证该字段的所有数据都是唯一、不重复的 | UNIQUE |
| 主键约束 | 主键是一行数据的唯一标识,要求非空且唯一 | PRIMARY KEY |
| 默认约束 | 保存数据时,如果未指定该字段的值,则采用默认值 | DEFAULT |
| 检查约束(8.0.1版本后) | 保证字段值满足某一个条件 | CHECK |
| 外键约束 | 用来让两张图的数据之间建立连接,保证数据的一致性和完整性 | FOREIGN KEY |
约束是作用于表中字段上的,可以再创建表/修改表的时候添加约束。
2. 常用约束
| 约束条件 | 关键字 |
|---|---|
| 主键 | PRIMARY KEY |
| 自动增长 | AUTO_INCREMENT |
| 不为空 | NOT NULL |
| 唯一 | UNIQUE |
| 逻辑条件 | CHECK |
| 默认值 | DEFAULT |
代码示例:
1 | create table user( |
3. 外键约束
(1) 添加外键
方法一:
1 | CREATE TABLE 表名( |
方法二:
1 | ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名) REFERENCES 主表(主表列名); |
(2) 删除外键:
1 | ALTER TABLE 表名 DROP FOREIGN KEY 外键名; |
(2) 删除/更新行为
| 行为 | 说明 |
|---|---|
| NO ACTION | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则不允许删除/更新(与RESTRICT一致) |
| RESTRICT | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则不允许删除/更新(与NO ACTION一致) |
| CASCADE | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则也删除/更新外键在子表中的记录 |
| SET NULL | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则设置子表中该外键值为null(要求该外键允许为null) |
| SET DEFAULT(不重要) | 父表有变更时,子表将外键设为一个默认值(Innodb不支持) |
(3) 更改删除/更新行为:
1 | ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段) REFERENCES 主表名(主表字段名) ON UPDATE 行为 ON DELETE 行为; |
多表查询
1. 多表关系
- 一对多(多对一)
- 多对多
- 一对一
(1) 一对多
案例:部门与员工
关系:一个部门对应多个员工,一个员工对应一个部门
实现:在多的一方建立外键,指向一的一方的主键
(2) 多对多
案例:学生与课程
关系:一个学生可以选多门课程,一门课程也可以供多个学生选修
实现:建立第三张中间表,中间表至少包含两个外键,分别关联两方主键
(3) 一对一
案例:用户与用户详情
关系:一对一关系,多用于单表拆分,将一张表的基础字段放在一张表中,其他详情字段放在另一张表中,以提升操作效率
实现:在任意一方加入外键,关联另外一方的主键,并且设置外键为唯一的(UNIQUE)
2. 查询
(1) 合并查询(笛卡尔积,会展示所有组合结果):
1 | select * from employee, dept; |
- 笛卡尔积:两个集合A集合和B集合的所有组合情况(在多表查询时,需要消除无效的笛卡尔积)
(2) 消除无效笛卡尔积:
1 | select * from emp, dept where dept_id = dept.id; |
(3) 内连接查询
① 内连接查询的是两张表交集的部分,即如图的绿色部分

② 隐式内连接:
1 | SELECT 字段列表 FROM 表1, 表2 WHERE 条件 ...; |
③ 显式内连接:
1 | SELECT 字段列表 FROM 表1 [ INNER ] JOIN 表2 ON 连接条件 ...; |
④ 代码示例:
1 | -- 隐式内连接 |
(4) 外连接查询
① 左外连接:查询左表所有数据,以及两张表交集部分数据(相当于蓝色部分 + 绿色部分),相当于查询表1的所有数据,包含表1和表2交集部分数据
1 | SELECT 字段列表 FROM 表1 LEFT [ OUTER ] JOIN 表2 ON 条件 ...; |

② 右外连接:查询右表所有数据,以及两张表交集部分数据,相当于查询表 2 的所有数据,同时包含表 1 与表 2 交集部分数据
1 | SELECT 字段列表 FROM 表1 RIGHT [ OUTER ] JOIN 表2 ON 条件 ...; |
③ 代码示例:
1 | -- 左 |
关键逻辑:
1 | select d.name, e.* from dept d left outer join emp e on e.dept = d.id; |
- 表顺序:
dept d(左表) ← LEFT JOIN →emp e(右表) - 连接类型:左连接 → 保 “左表(dept)” 的所有行
- 逻辑:返回
dept的所有部门(哪怕这个部门没有员工),同时匹配emp中该部门的员工数据
1 | select d.name, e.* from employee as e right outer join dept as d on e.dept = d.id; |
- 表顺序:
employee e(左表) ← RIGHT JOIN →dept d(右表) - 连接类型:右连接 → 保 “右表(dept)” 的所有行
- 逻辑:返回
dept的所有部门(哪怕这个部门没有员工),同时匹配emp中该部门的员工数据
(5) 自连接查询
① 当前表与自身的连接查询,自连接必须使用表别名
② 语法:
1 | SELECT 字段列表 FROM 表A 别名A JOIN 表A 别名B ON 条件 ...; |
自连接查询,可以是内连接查询,也可以是外连接查询
③ 代码示例:
1 | -- 查询员工及其所属领导的名字 |
(6) 联合查询 union, union all
① 把多次查询的结果合并,形成一个新的查询集
② 语法:
1 | SELECT 字段列表 FROM 表A ... |
③ 注意事项
- UNION ALL 会有重复结果,UNION 不会
- 联合查询比使用or效率高,不会使索引失效
3. 子查询
(1) SQL语句中嵌套SELECT语句,称谓嵌套查询,又称子查询。
(2) 语法:
1 | SELECT * FROM t1 WHERE column1 = ( SELECT column1 FROM t2); |
子查询外部的语句可以是 INSERT / UPDATE / DELETE / SELECT 的任何一个
③ 根据子查询结果可以分为:
- 标量子查询(子查询结果为单个值)
- 列子查询(子查询结果为一列)
- 行子查询(子查询结果为一行)
- 表子查询(子查询结果为多行多列)
④ 根据子查询位置可分为:
- WHERE 之后
- FROM 之后
- SELECT 之后
(3) 标量子查询
① 子查询返回的结果是单个值(数字、字符串、日期等)。
② 常用操作符:-、<>、>、>=、<、<=
**注意:**在 MySQL 中,<>是 “不等于” 的比较操作符,用于判断两个值是否不相等,等价于!=(二者是完全相同的含义)
③ 代码示例:
1 | select id from dept where name = '销售部'; |
(4) 列子查询
① 返回的结果是一列(可以是多行)。
② 常用操作符:
| 操作符 | 描述 |
|---|---|
| IN | 在指定的集合范围内,多选一 |
| NOT IN | 不在指定的集合范围内 |
| ANY | 子查询返回列表中,有任意一个满足即可 |
| SOME | 与ANY等同,使用SOME的地方都可以使用ANY |
| ALL | 子查询返回列表的所有值都必须满足 |
③ 代码示例:
1 | -- 查询财务部所有人的工资 |
(5) 行子查询
① 返回的结果是一行(可以是多列)。
② 常用操作符:=, <, >, IN, NOT IN
③ 代码示例:
1 | -- 查询与xxx的薪资及直属领导相同的员工信息 |
(6) 表子查询
① 返回的结果是多行多列
② 常用操作符:IN
③ 代码示例:
1 | -- 查询与 “鹿杖客”,“宋远桥” 的职位和薪资相同的员工信息 |
关键逻辑:重点理解外面的「主查询」
遍历emp表的每一个员工,取出他的job和salary组成一个 “组合对”,看这个组合对是否在子查询的 “模板列表” 里(也就是是否是(职员,3750)或(销售,4600)),如果在,就把这个员工的所有信息查出来。
1 | -- 查询入职日期是 “2006-01-01” 之后的员工信息及其部门信息 |
4. 综合练习
(1) 查询年龄小于30岁的员工的姓名、年龄、职位、部门信息(显式内连接)
1 | select e.name, e.age, e.job, d.name from emp e inner join dept d on e.dept_id = d.id where e.age < 30; |
关键逻辑:显式内连接(INNER JOIN)的标准语法结构是:
1 | SELECT 字段 |
① ON是JOIN的 “配套条件”—— 数据库要求,只要写JOIN关联两张表,就必须用ON指定 “两张表怎么关联”,所以ON必须紧跟在JOIN 表2之后;
② WHERE是对 “关联后的结果集” 做筛选,只能放在最后。
(2) 查询拥有员工的部门ID、部门名称
1 | select distinct d.id, d.name from emp e, dept d where e.dept_id = d.id; |
易错点:忘记加 distinct
(3) 查询低于本部门平均工资的员工信息
1 | select * from emp e2 where e2.salary < (select avg(e1.salary) from emp e1 where e1.dept_id = e2.dept_id); |
关键逻辑:
拆分成先算出每个部门的平均工资,再查询低于本部门平均工资的员工信息
1 | select avg(e1.salary) from emp e1 where e1.dept_id = 1; |
事务
事务是一组操作的集合,事务会把所有操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。
1. 基本操作:
1 | -- 1. 查询张三账户余额 |
2. 操作方式二
(1) 开启事务:
1 | START TRANSACTION 或 BEGIN TRANSACTION; |
(2) 提交事务:
1 | COMMIT; |
(3) 回滚事务:
1 | ROLLBACK; |
(4) 操作实例:
1 | start transaction; |
3. 四大特性ACID
- 原子性(Atomicity):事务是不可分割的最小操作单元,要么全部成功,要么全部失败
- 一致性(Consistency):事务完成时,必须使所有数据都保持一致状态
- 隔离性(Isolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行
- 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变就是永久的
4. 并发事务
(1) 并发事务问题
| 问题 | 描述 |
|---|---|
| 脏读 | 一个事务读到另一个事务还没提交的数据 |
| 不可重复读 | 一个事务先后读取同一条记录,但两次读取的数据不同 |
| 幻读 | 一个事务按照条件查询数据时,没有对应的数据行,但是再插入数据时,又发现这行数据已经存在 |
(2) 并发事务隔离级别:
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| Read uncommitted(读未提交) | √ | √ | √ |
| Read committed(读已提交) | × | √ | √ |
| Repeatable Read(默认) | × | × | √ |
| Serializable(串行化) | × | × | × |
- √表示在当前隔离级别下该问题会出现
- Serializable 性能最低;Read uncommitted 性能最高,数据安全性最差
① 查看事务隔离级别:
1 | SELECT @@TRANSACTION_ISOLATION; |
② 设置事务隔离级别:
1 | SET [ SESSION | GLOBAL ] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }; |
SESSION 是会话级别,表示只针对当前会话有效,GLOBAL 表示对所有会话有效
创建数据库的流程
- 点击左侧界面 **“Create data source”,**在弹出的菜单中,选择 “MySQL”

- 填写 MySQL 连接信息,输入User、Password

- 下载 MySQL 驱动(首次连接需要),界面会提示 “Download missing driver files”(缺少驱动文件),点击这个提示 → 选择自动下载驱动
- 填写完信息 + 下载驱动后,点击窗口右下角的 **“Test Connection”,**最后点击 “Apply”→“OK”
MySQL 进阶篇
存储引擎
1. MySQL体系结构:

(1) 连接层:最上层是一些客户端和链接服务,主要完成一些类似于连接处理、授权认证、及相关的安全方案。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
(2) 服务层:第二层架构主要完成大多数的核心服务功能,如 SQL 接口,并完成缓存的查询,SQL 的分析和优化,部分内置函数的执行。所有跨存储引擎的功能也在这一层实现,如过程、函数等。
(3) 引擎层:存储引擎真正的负责了 MySQL 中数据的存储和提取,服务器通过 API 和存储引擎进行通信。不同的存储引擎具有不同的功能,这样我们可以根据自己的需要,来选取合适的存储引擎。
(4) 存储层:主要是将数据存储在文件系统之上,并完成与存储引擎的交互。
2. 存储引擎
(1) 存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表而不是基于库的,所以存储引擎也可以被称为表引擎。
(2) 默认存储引擎是InnoDB。
(3) 相关操作:
1 | -- 查询建表语句 |
3. InnoDB
(1) InnoDB 是一种兼顾高可靠性和高性能的通用存储引擎,在 MySQL 5.5 之后,InnoDB 是默认的 MySQL 引擎
(2) 特点:
- DML 操作遵循 ACID 模型,支持事务
- 行级锁,提高并发访问性能
- 支持外键约束,保证数据的完整性和正确性
① 表锁:锁住整个表的锁。当某个人操作(增删改)这个表时,会把整个表 “锁起来”,其他人在锁释放前,不能操作这个表的任何数据。
② 行锁(hang suo):只锁住表中某一行(或几行)数据的锁。当某个人操作某一行时,只锁这一行,其他行的数据还是可以被其他人正常操作。
(3) 文件:
- xxx.ibd: xxx代表表名,InnoDB 引擎的每张表都会对应这样一个表空间文件,存储该表的表结构(frm、sdi)、数据和索引。
参数:innodb_file_per_table,决定多张表共享一个表空间还是每张表对应一个表空间
(4) InnoDB 逻辑存储结构:

4. MyISAM
(1) MyISAM 是 MySQL 早期的默认存储引擎。
(2) 特点:
- 不支持事务,不支持外键
- 支持表锁,不支持行锁
- 访问速度快
(3) 文件:
- xxx.sdi: 存储表结构信息
- xxx.MYD: 存储数据
- xxx.MYI: 存储索引
5. Memory
(1) Memory 引擎的表数据是存储在内存中的,受硬件问题、断电问题的影响,只能将这些表作为临时表或缓存使用。
(2) 特点:
- 存放在内存中,速度快
- hash索引(默认)
(3) 文件:
- xxx.sdi: 存储表结构信息
6. 存储引擎特点
| 特点 | InnoDB | MyISAM | Memory |
|---|---|---|---|
| 存储限制 | 64TB | 有 | 有 |
| 事务安全 | 支持 | - | - |
| 锁机制 | 行锁 | 表锁 | 表锁 |
| B+tree索引 | 支持 | 支持 | 支持 |
| Hash索引 | - | - | 支持 |
| 全文索引 | 支持(5.6版本之后) | 支持 | - |
| 空间使用 | 高 | 低 | N/A |
| 内存使用 | 高 | 低 | 中等 |
| 批量插入速度 | 低 | 高 | 高 |
| 支持外键 | 支持 | - | - |
7. 存储引擎的选择
(1) 在选择存储引擎时,应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统,还可以根据实际情况选择多种存储引擎进行组合。
- InnoDB: 如果应用对事物的完整性有比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包含很多的更新、删除操作,则 InnoDB 是比较合适的选择
- MyISAM: 如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不高,那这个存储引擎是非常合适的。
- Memory: 将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。Memory 的缺陷是对表的大小有限制,太大的表无法缓存在内存中,而且无法保障数据的安全性
电商中的足迹和评论适合使用 MyISAM 引擎,缓存适合使用 Memory 引擎。
索引
索引是帮助 MySQL 高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查询算法,这种数据结构就是索引。
1. 优缺点:
① 优点:
- 提高数据检索效率,降低数据库的IO成本
- 通过索引列对数据进行排序,降低数据排序的成本,降低CPU的消耗
② 缺点:
- 索引列也是要占用空间的
- 索引大大提高了查询效率,但降低了更新的速度,比如 INSERT、UPDATE、DELETE
2. 索引结构
| 索引结构 | 描述 |
|---|---|
| B+Tree | 最常见的索引类型,大部分引擎都支持B+树索引 |
| Hash | 底层数据结构是用哈希表实现,只有精确匹配索引列的查询才有效,不支持范围查询 |
| R-Tree(空间索引) | 空间索引是 MyISAM 引擎的一个特殊索引类型,主要用于地理空间数据类型,通常使用较少 |
| Full-Text(全文索引) | 是一种通过建立倒排索引,快速匹配文档的方式,类似于 Lucene, Solr, ES |
| 索引 | InnoDB | MyISAM | Memory |
|---|---|---|---|
| B+Tree索引 | 支持 | 支持 | 支持 |
| Hash索引 | 不支持 | 不支持 | 支持 |
| R-Tree索引 | 不支持 | 支持 | 不支持 |
| Full-text | 5.6版本后支持 | 支持 | 不支持 |
(1) B-Tree(多路平衡查找树)

① 二叉树缺点:顺序插入时,会形成一个链表,查询性能大大降低。大数据量情况下,层级较深,检索速度慢。而二叉树的缺点可以用红黑树来解决:

② 红黑树也存在大数据量情况下,层级较深,检索速度慢的问题。为了解决上述问题,可以使用 B-Tree 结构。
③ B-Tree 以一棵最大度数(max-degree,指一个节点的子节点个数)为5(5阶)的 b-tree 为例(每个节点最多存储4个key,5个指针)

(2) B+Tree

① 与 B-Tree 的区别:
- 所有的数据都会出现在叶子节点
- 叶子节点形成一个单向链表
② MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上,增加一个指向相邻叶子节点的链表指针,就形成了带有顺序指针的 B+Tree,提高区间访问的性能。

(3) Hash
① 哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中。如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了hash冲突(也称为hash碰撞),可以通过链表来解决。

② 特点:
- Hash索引只能用于对等比较(=、in),不支持范围查询(betwwn、>、<、…)
- 无法利用索引完成排序操作
- 查询效率高,通常只需要一次检索就可以了,效率通常要高于 B+Tree 索引
③ 存储引擎支持:
- Memory
- InnoDB: 具有自适应hash功能,hash索引是存储引擎根据 B+Tree 索引在指定条件下自动构建的
(4) 面试题:为什么 InnoDB 存储引擎选择使用 B+Tree 索引结构?
- 相对于二叉树,层级更少,搜索效率高
- 对于 B-Tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储的键值减少,指针也跟着减少,要同样保存大量数据,只能增加树的高度,导致性能降低
- 相对于 Hash 索引,B+Tree 支持范围匹配及排序操作
3. 索引分类
| 分类 | 含义 | 特点 | 关键字 |
|---|---|---|---|
| 主键索引 | 针对于表中主键创建的索引 | 默认自动创建,只能有一个 | PRIMARY |
| 唯一索引 | 避免同一个表中某数据列中的值重复 | 可以有多个 | UNIQUE |
| 常规索引 | 快速定位特定数据 | 可以有多个 | |
| 全文索引 | 全文索引查找的是文本中的关键词,而不是比较索引中的值 | 可以有多个 | FULLTEXT |
(1) 在 InnoDB 存储引擎中,根据索引的存储形式,又可以分为以下两种:
| 分类 | 含义 | 特点 |
|---|---|---|
| 聚集索引(Clustered Index) | 将数据存储与索引放一块,索引结构的叶子节点保存了行数据 | 必须有,而且只有一个 |
| 二级索引(Secondary Index) | 将数据与索引分开存储,索引结构的叶子节点关联的是对应的主键 | 可以存在多个 |
Q:叶子节点是什么?
A:叶子节点是 树结构中没有子节点的节点,也就是树的「最底层终端节点」
(2) 演示图:

(3) 聚集索引选取规则:
- 如果存在主键,主键索引就是聚集索引
- 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引
- 如果表没有主键或没有合适的唯一索引,则 InnoDB 会自动生成一个 rowid 作为隐藏的聚集索引
(4) 思考题
① 以下 SQL 语句,哪个执行效率高?为什么?
1 | select * from user where id = 10; |
答:第一条语句,因为第二条需要回表查询,相当于两个步骤。
(2) InnoDB 主键索引的 B+Tree 高度为多少?
答:假设一行数据大小为1k,一页中可以存储16行这样的数据。InnoDB 的指针占用6个字节的空间,主键假设为bigint,占用字节数为8,可得公式:
1 | n×8(主键总大小) + (n+1)×6(指针总大小) = 16×1024(页大小) |
其中 8 表示 bigint 占用的字节数,n 表示当前节点存储的key的数量,(n + 1) 表示指针数量(比key多一个)。算出n约为1170。
① 如果树的高度为2,那么他能存储的数据量为:
- 根节点是 1 个非叶子节点,有 1171 个指针;
- 每个指针对应 1 个叶子节点,每个叶子节点存 16 行;
- 总数据量 = 1171(叶子节点数量) × 16(每个叶子节点行数) = 18736 行。
② 如果树的高度为3,那么他能存储的数据量为:1171 * 1171 * 16 = 21939856。
- 根节点有 1171 个指针,对应 1171 个中间层非叶子节点;
- 每个中间层非叶子节点又有 1171 个指针,对应 1171 个叶子节点;
- 总数据量 = 1171(中间层数量) × 1171(叶子节点数量) × 16(每个叶子节点行数) ≈ 2193 万行。
4. 语法
(1) 创建索引:
1 | CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name, ...); |
如果 CREATE 后面不加索引类型参数,则创建的是常规索引
(2) 查看索引:
1 | SHOW INDEX FROM table_name; |
(3) 删除索引:
1 | DROP INDEX index_name ON table_name; |
(4) 案例:
1 | -- name字段为姓名字段,该字段的值可能会重复,为该字段创建索引 |
5. 性能分析
(1) 查看执行频次
查看当前数据库的 INSERT, UPDATE, DELETE, SELECT 访问频次:
1 | SHOW GLOBAL STATUS LIKE 'Com_______'; |
(2) 慢查询日志
① 慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认10秒)的所有SQL语句的日志。
② MySQL的慢查询日志默认没有开启,需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息:
1 | # 开启慢查询日志开关 |
③ 查看慢查询日志开关状态:
1 | show variables like 'slow_query_log'; |
(3) profile
① show profile 能在做SQL优化时帮我们了解时间都耗费在哪里。通过 have_profiling 参数,能看到当前 MySQL 是否支持 profile 操作:
1 | SELECT @@have_profiling; |
② profiling 默认关闭,可以通过set语句在session/global级别开启 profiling:
1 | SET profiling = 1; |
③ 查看所有语句的耗时:
1 | show profiles; |
④ 查看指定query_id的SQL语句各个阶段的耗时:
1 | show profile for query query_id; |
⑤ 查看指定query_id的SQL语句CPU的使用情况
1 | show profile cpu for query query_id; |
(4) explain
① EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
② 语法:
1 | # 直接在select语句之前加上关键字 explain / desc |
③ EXPLAIN 各字段含义:
- id:select 查询的序列号,表示查询中执行 select 子句或者操作表的顺序(id相同,执行顺序从上到下;id不同,值越大越先执行)
- select_type:表示 SELECT 的类型,常见取值有 SIMPLE(简单表,即不适用表连接或者子查询)、PRIMARY(主查询,即外层的查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含了子查询)等
- type:表示连接类型,性能由好到差的连接类型为 NULL、system、const、eq_ref、ref、range、index、all
- possible_key:可能应用在这张表上的索引,一个或多个
- Key:实际使用的索引,如果为 NULL,则没有使用索引
- Key_len:表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下,长度越短越好
- rows:MySQL认为必须要执行的行数,在InnoDB引擎的表中,是一个估计值,可能并不总是准确的
- filtered:表示返回结果的行数占需读取行数的百分比,filtered的值越大越好
6. 使用规则
(1) 最左前缀法则
① 如果索引关联了多列(联合索引),要遵守最左前缀法则,最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列。
② 如果跳跃某一列,索引将部分失效(后面的字段索引失效)。
③ 代码示例:
1 | -- 走索引,跟顺序没关系 |
④ 联合索引中,出现范围查询(<, >),范围查询右侧的列索引失效。可以用 >= 或者 <= 来规避索引失效问题。
(2) 索引失效情况
① 在索引列上进行运算操作,索引将失效。例如:
1 | explain select * from tb_user where substring(phone, 10, 2) = '15'; |
② 字符串类型字段使用时,不加引号,索引将失效。例如:
1 | -- 此处phone的值没有加引号 |
③ 模糊查询中,如果仅仅是尾部模糊匹配,索引不会是失效;如果是头部模糊匹配,索引失效。例如:
1 | -- 索引失效 |
④ 用 or 分割开的条件,如果 or 其中一个条件的列没有索引,那么涉及的索引都不会被用到。只有两侧都有索引的时候,索引才会生效。如果要让数据的索引不失效,那么要给没有索引的创建索引。
1 | -- 假设 age 无索引,则第一句索引失效 |
⑤ 如果 MySQL 评估使用索引比全表更慢,则不使用索引。
7. SQL 提示
这是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化操作的目的。例如:
① 使用索引:
1 | explain select * from tb_user use index(idx_user_pro) where profession="软件工程"; |
② 不使用哪个索引:
1 | explain select * from tb_user ignore index(idx_user_pro) where profession="软件工程"; |
③ 必须使用哪个索引:
1 | explain select * from tb_user force index(idx_user_pro) where profession="软件工程"; |
use 是建议,实际使用哪个索引 MySQL 还会自己权衡运行速度去更改,force就是无论如何都强制使用该索引。
8. 覆盖索引&回表查询
(1) 尽量使用覆盖索引(查询使用了索引,并且需要返回的列,在该索引中已经全部能找到),减少 select *。explain 中 extra 字段含义:
① using index condition:查找使用了索引,但是需要回表查询数据
② using where; using index;:查找使用了索引,但是需要的数据都在索引列中能找到,所以不需要回表查询
(2) 如果在辅助索引中找聚集索引,只需要通过辅助索引(name)查找到对应的id,返回name和name索引对应的id即可,只需要一次查询。例如:
1 | select id, name from xxx where name='xxx'; |
(3) 如果是通过辅助索引查找其他字段,则需要回表查询,例如:
1 | select id, name, gender from xxx where name='xxx'; |
(4) 所以尽量不要用select *,容易出现回表查询,降低效率,除非有联合索引包含了所有字段

(5) 面试题:一张表,有四个字段(id, username, password, status),由于数据量大,需要对以下SQL语句进行优化,该如何进行才是最优方案:
1 | select id, username, password from tb_user where username='itcast'; |
解:给username和password字段建立联合索引,则不需要回表查询,直接覆盖索引,这个优化的核心就是「让索引覆盖查询所需的所有字段」:
- 利用 InnoDB 二级索引默认带主键的特性;
- 把查询需要的非主键字段(password、username)加到联合索引里;
- 最终实现 “一次索引查询就能拿到所有数据”,彻底规避回表的性能损耗。
9. 前缀索引
(1) 当字段类型为字符串(varchar, text等)时,有时候需要索引很长的字符串,这会让索引变得很大,查询时,浪费大量的磁盘IO,影响查询效率,此时可以只将字符串的一部分前缀,建立索引,这样可以大大节约索引空间,从而提高索引效率。
(2) 语法:
1 | create index idx_xxxx on table_name(columnn(n)); |
(3) 前缀长度:可以根据索引的选择性来决定,而选择性是指不重复的索引值(基数)和数据表的记录总数的比值,**索引选择性越高则查询效率越高,**唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的。
(4) 求选择性公式:
1 | select count(distinct email) / count(*) from tb_user; |
show index 里面的sub_part可以看到接取的长度
10. 单列索引&联合索引
(1) 概念
① 单列索引:即一个索引只包含单个列
② 联合索引:即一个索引包含了多个列
在业务场景中,如果存在多个查询条件,考虑针对于查询字段建立索引时,建议建立联合索引,而非单列索引。
(2) 单列索引情况:
1 | -- 这句只会用到phone索引字段 |
注意事项
- 多条件联合查询时,MySQL优化器会评估哪个字段的索引效率更高,会选择该索引完成本次查询
(3) 设计原则
① 针对于数据量较大,且查询比较频繁的表建立索引
② 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引
③ 尽量选择区分度高的列作为索引,尽量**建立唯一索引,**区分度越高,使用索引的效率越高
④ 如果是字符串类型的字段,字段长度较长,可以针对于字段的特点,建立前缀索引
⑤ 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间,避免回表,提高查询效率
⑥ 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价就越大,会影响增删改的效率
⑦ 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时,它可以更好地确定哪个索引最有效地用于查询
SQL 优化
1. 插入数据
(1) 普通插入
① 采用批量插入(一次插入的数据不建议超过1000条)
1 | Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry'); |
② 手动提交事务
1 | start transaction; |
③ 主键顺序插入
1 | 主键乱序插入:8 1 9 21 88 2 4 15 89 5 7 3 |
(2) 大批量插入:
如果一次性需要插入大批量数据,使用insert语句插入性能较低,此时可以使用MySQL数据库提供的load指令插入。
1 | # 客户端连接服务端时,加上参数 --local-infile(这一行在bash/cmd界面输入) |
2. 主键优化
(1) 数据组织方式:
在InnoDB存储引擎中,表数据都是根据主键顺序组织存放的,这种存储方式的表称为索引组织表(Index organized table, IOT)

数据库的存储是:
表空间(Tablespace) → 段(Segment) → 区(Extent) → 页(Page) → 行(Row)
(2) 页分裂:
页可以为空,也可以填充一半,也可以填充100%,每个页包含了2-N行数据(如果一行数据过大,会行溢出),根据主键排列。
① 触发场景:当你往表中插入数据时,InnoDB 会把数据存到对应的页里。如果当前页已经没有足够空间存新行(比如页的使用率快满了),就会触发 “页分裂”。
② 典型过程(以非自增主键插入为例)

步骤 1:插入前的页状态
- 1# 页:存了主键
1、5、9、23、47的 5 条数据(页已经快存满了); - 2# 页:存了主键
55、67、89、101、107的 5 条数据; - 现在要插入 主键 = 50 的新行。

步骤 2:插入时的 “位置冲突”
主键是有序存储的,50 的大小介于 1# 页的最大主键(47)和 2# 页的最小主键(55)之间,所以50 应该存在 1# 和 2# 页之间。
但问题是:1# 页已经快存满了,没有空间放 50 这条新数据 → 触发页分裂。
步骤 3:页分裂后的结果
分裂后:
- 1# 页:把原来的部分数据(23、47)移出去,只留
1、5、9; - 新建 3# 页:把移出的 23、47,加上新插入的 50,存在 3# 页(主键
23、47、50); - 2# 页:保持原来的
55、67、89、101、107不变。

(3) 页合并:
当删除一行记录时,实际上记录并没有被物理删除,只是记录被标记(flaged)为删除并且它的空间变得允许被其他记录声明使用。当页中删除的记录到达 MERGE_THRESHOLD(默认为页的50%),InnoDB会开始寻找最靠近的页(前后)看看是否可以将这两个页合并以优化空间使用。
MERGE_THRESHOLD:合并页的阈值,可以自己设置,在创建表或创建索引时指定
(4) 主键设计原则:
- 满足业务需求的情况下,尽量降低主键的长度。主键越长,每个 “索引页(Page)” 能存的主键数量就越少 → 索引树的层数会变多
- 插入数据时,尽量选择顺序插入,选择使用 AUTO_INCREMENT 自增主键
- 尽量不要使用 UUID 做主键或者是其他的自然主键,如身份证号。UUID 是随机生成的,插入时会像之前 “插入 50” 那样,随机插在页的中间位置 → 频繁触发页分裂,既耗性能又产生碎片;
- 业务操作时,避免对主键的修改
3. order by 优化
(1) Using filesort:
通过表的索引或全表扫描,读取满足条件的数据行,然后在排序缓冲区 sort buffer 中完成排序操作,所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序
(2) Using index:
通过有序索引顺序扫描直接返回有序数据,这种情况即为 using index,不需要额外排序,操作效率高
(3) 如果order by字段全部使用升序排序或者降序排序,则都会走索引,但是如果一个字段升序排序,另一个字段降序排序,则不会走索引,explain的extra信息显示的是Using index, Using filesort,如果要优化掉Using filesort,则需要另外再创建一个索引,如:create index idx_user_age_phone_ad on tb_user(age asc, phone desc);,此时使用select id, age, phone from tb_user order by age asc, phone desc;会全部走索引
1 | -- 创建索引 |
(4) 总结:
- 根据排序字段建立合适的索引,多字段排序时,也遵循最左前缀法则
- 尽量使用覆盖索引
- 多字段排序,一个升序一个降序,此时需要注意联合索引在创建时的规则(ASC/DESC)
- 如果不可避免出现filesort,大数据量排序时,可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)
4. group by优化
(1) 在分组操作时,可以通过索引来提高效率
(2) 分组操作时,索引的使用也是遵循最左前缀法则的
1 | -- 创建索引 |
如索引为idx_user_pro_age_stat,则句式可以是select ... where profession order by age,这样也符合最左前缀法则
5. limit优化
(1) 常见的问题:
如limit 2000000, 10,此时需要 MySQL 排序前2000000条记录,但仅仅返回2000000 - 2000010的记录,其他记录丢弃,查询排序的代价非常大。
(2) 优化方案:
一般分页查询时,通过创建覆盖索引能够比较好地提高性能,可以通过覆盖索引加子查询形式进行优化
(3) 例如:
1 | - 此语句耗时很长 |
4. count优化
(1) MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count(*) 的时候会直接返回这个数,效率很高(前提是不适用where);
(2) InnoDB 在执行 count(*) 时,需要把数据一行一行地从引擎里面读出来,然后累计计数。
(3) 优化方案:自己计数,如创建key-value表存储在内存或硬盘,或者是用redis
(4) count 的几种用法:
① 如果 count 函数的参数(count里面写的那个字段)不是NULL(字段值不为NULL),累计值就加一,最后返回累计值
② 用法:count(*)、count(主键)、count(字段)、count(1)
③ count(主键) 跟 count() 一样,因为主键不能为空;count(字段) 只计算字段值不为NULL的行;count(1)引擎会为每行添加一个1,然后就count这个1,返回结果也跟count()一样;count(null)返回0
(5) 各种用法的性能:
① count(主键):InnoDB引擎会遍历整张表,把每行的主键id值都取出来,返回给服务层,服务层拿到主键后,直接按行进行累加(主键不可能为空)
② count(字段):没有not null约束的话,InnoDB引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,服务层判断是否为null,不为null,计数累加;有not null约束的话,InnoDB引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,直接按行进行累加
③ count(1):InnoDB 引擎遍历整张表,但不取值。服务层对于返回的每一层,放一个数字 1 进去,直接按行进行累加
④ count(*):InnoDB 引擎并不会把全部字段取出来,而是专门做了优化,不取值,服务层直接按行进行累加
按效率排序:count(字段) < count(主键) < count(1) < count(),所以尽量使用 count()
5. update优化(避免行锁升级为表锁)
(1) InnoDB 的行锁是针对索引加的锁,不是针对记录加的锁,并且该索引不能失效,否则会从行锁升级为表锁。
(2) 案例:
1 | -- 这句由于id有主键索引,所以只会锁这一行 |
视图
1. 介绍
(1) 视图(View)是一种虚拟存在的表。视图中的数据并不在数据库中实际存在,行和列数据来自定义视图的查询中使用的表,并且是在使用视图时动态生成的。
(2) 通俗的讲,视图只保存了查询的SQL逻辑,不保存查询结果。所以我们在创建视图的时候,主要的工作就落在创建这条SQL查询语句上。
2. 语法
(1) 创建视图:
1 | CREATE [OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION |
(2) 查询视图:
① 查看创建视图语句:
1 | SHOW CRETE VIEW 视图名称; |
② 查看视图数据:
1 | SELECT * FROM 视图名称…; |
(3) 修改视图:
① 方式一:
1 | CREATE [OR REPLACE] VIEW 视图名称[(列名列表)] AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION |
② 方式二:
1 | ALTER VIEW 视图名称[(列名列表)] AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION] |
(4) 删除视图:
1 | DROP VIEW [IF EXISTS]视图名称 [,视图名称] |
(5) 案例:
1 | -- 创建视图 |
3. 检查选项
(1) 视图的检查选项:
① 当使用 WITH CHECK OPTION 子句创建视图时,MySQL 会通过视图检查正在更改的每个行,例如:插入,更新,删除,以使其符合视图的定义。MySQL 允许基于另一个视图创建视图,它还会检查依赖视图中的规则以保持一致性。
② 为了确定检查的范围,mysql 提供了两个选项:CASCADED 和 LOCAL,默认值为CASCADED。
- cascaded:在对创建时含有该字段的视图,插入数据时,该视图依赖的视图都会加上检查,需要所有条件都满足才能够插入成功。
- local:在对创建时含有该字段的视图,插入数据时,对于该视图依赖的视图中含有检查语句的条件进行检查判断。
(2) with cascaded check option 的案例:
1 | -- 创建视图,但不加 with check option |
① 向无WITH CHECK OPTION的视图插入数据时,只要满足基表(student)的约束,插入会成功(但不满足视图筛选条件的行,不会显示在视图中)。
② 向有WITH CHECK OPTION的视图插入数据时,必须满足当前视图 + 所有底层视图的筛选条件(cascaded是级联检查所有底层视图),否则插入失败。
(3) with local check option 的案例:
1 | -- 创建视图 |
(4) 总结
① 没有 CHECK OPTION:不会检查当前视图的WHERE条件,即使数据不满足该条件,也能成功存入基表;但后续查询该视图时,这条不满足条件的数据不会在视图结果中显示
② 有 check option:会按LOCAL/CASCADED的规则检查对应范围的WHERE条件(当前视图 / 底层视图),不满足条件则插入 / 更新操作直接失败,数据既不会存入基表,自然也不会在视图中显示
4. 更新及作用
(1) 视图的更新:
要使视图可更新,视图中的行与基础表中的行之间必须存在一对一的关系。如果视图包含以下任何一项,则该视图不可更新:
- 聚合函数或窗口函数(SUM()、MIN()、MAX()、COUNT()等
- DISTINCT
- GROUP BY
- HAVINGA
- UNION 或者 UNION ALL
(2) 作用:
**① 简单:**视图不仅可以简化用户对数据的理解,也可以简化他们的操作。那些被经常使用的查询可以被定义为视图,从而使得用户不必为以后的操作每次指定全部的条件。
**② 安全:**数据库可以授权,但不能授权到数据库特定行和特定的列上。通过视图用户只能查询和修改他们所能见到的数据。
**③ 数据独立:**视图可帮助用户屏蔽真实表结构变化带来的影响。
(3) 案例:
1 | -- 1.为了保证数据库表的安全性,开发人员在操作tb_user表时,只能看到的用户的基本字段,屏蔽手机号和邮箱两个字段。 |
存储过程
1. 介绍
(1) 存储过程是事先经过编译并存储在数据库中的一段 SQL语句的集合,调用存储过程可以简化应用开发人员的很多工作,减少数据在数据库和应用服务器之间的传输,对于提高数据处理的效率是有好处的。
(2) 存储过程思想上很简单,就是数据库 SOL语言层面的代码封装与重用。
2. 特点:
- 封装,复用
- 可以接收参数,也可以返回数据
- 减少网络交互,效率提升
3. 基本语法
(1) 创建:
1 | CREATE PROCEDURE 存储过程名称([参数列表]) |
(2) 调用:
1 | CALL 名称([参数]); |
(3) 查看:
1 | -- 查询数据库的存储过程及状态信息 |
(4) 删除:
1 | DROP PROCEDURE [IF EXISTS] 存储过程名称; |
(5) 案例:
1 | -- 存储过程基本语法 |
4. 变量
(1) 系统变量
① 系统变量 是 MySQL 服务器提供,不是用户定义的,属于服务器层面。分为全局变量(GLOBAL)、会话变量(SESSION)。
② 查看系统变量
1 | -- 查看所有系统变量 |
③ 设置系统变量
1 | -- 语法1:直接指定作用域(SESSION/全局) |
④ 案例:
1 | -- 变量:系统变量 |
注意:
- 如果没有指定 session / global,默认 session,会话变量
- mysql 服务器重启之后,所设置的全局参数会失效,要想不失效,需要更改/etc/my.cnf 中的配置。
(2) 用户定义变量
① 用户定义变量 是用户根据需要自己定义的变量,用户变量不用提前声明,在用的时候直接用“@变量名”使用就可以。其作用域为当前连接。
② 赋值:
1 | SET @var name = expr [, @var_name = expr]...; |
③ 使用:
1 | SELECT @var_name; |
④ 案例:
1 | -- 变量:用户变量 |
注意:
用户定义的变量无需对其进行声明或者初始化,只不过获取到的值为 NULL。
(3) 局部变量
① 局部变量 是根据需要定义的在局部生效的变量,访问之前,需要DECLARE声明。可用作存储过程内的局部变量和输入参数,局部变量的范围是在其内声明的BEGIN .. END块。
② 声明:
1 | DECLARE 变量名 变量类型 [DEFAULT..]; |
变量类型就是数据库字段类型:INT、BIGINT、CHAR、VARCHAR、DATE、TIME等。
③ 赋值:
1 | SET 变量名=值; |
④ 案例:
1 | -- 变量:局部变量 |
5. if 判断
(1) 语法:
1 | IF 条件1 THEN |
(2) 案例:
1 | create procedure p3() |
6. 参数(in, out, inout)
| 类型 | 含义 | 备注 |
|---|---|---|
| IN | 该类参数作为输入,也就是需要调用时传入值 | 默认 |
| OUT | 该类参数作为输出,也就是该参数可以作为返回值 | |
| INOUT | 既可以作为输入参数,也可以作为输出参数**** |
(1) 用法:
1 | CREATE PROCEDURE 存储过程名称([IN/OUT/INOUT 参数名 参数类型 ]) |
(2) 案例:
1 | -- 根据传入(in)参数score,判定当前分数对应的分数等级,并返回(out) |
7. case
(1) 语法一:
1 | CASE case value |
(2) 语法二:
1 | CASE |
(3) 案例:
1 | -- case |
8. 循环
(1) while
① while 循环是有条件的循环控制语句。满足条件后,再执行循环体中的SQL语句。
② 语法:
1 | -- 先判定条件,如果条件为true,则执行逻辑,否则,不执行逻辑 |
③ 案例:
1 | -- while计算从1累加到 n 的值,n 为传入的参数值。 |
(2) repeat
① repeat是有条件的循环控制语句,当满足条件的时候退出循环。
② 语法:
1 | -- 先执行一次逻辑,然后判定逻辑是否满足,如果满足,则退出。如果不满足,则继续下一次循环 |
③ 案例:
1 | -- while计算从1累加到 n 的值,n 为传入的参数值。 |
④ 与 while 区别:
- 先进行循环一次再判断。相当于 c 语言中的 do while();
- 满足条件则退出
(3) loop
① LOOP 实现简单的循环,如果不在SQL逻辑中增加退出循环的条件,可以用其来实现简单的死循环。LOOP可以配合一下两个语句使用。
- LEAVE:配合循环使用,退出循环。
- ITERATE:必须用在循环中,作用是跳过当前循环剩下的语句,直接进入下一次循环。
② 语法:
1 | [begin label:] LOOP |
③ 案例:
1 | -- loop 计算从1到n之间的偶数累加的值,n为传入的参数值。 |
9. 游标-cursor
(1) 介绍
游标(CURSOR)是用来存储查询结果集的数据类型,在存储过程和函数中可以使用游标对结果集进行循环的处理。游标的使用包括游标的声明、OPEN、FETCH和 CLOSE,其语法分别如下。
① 声明游标
1 | DECLARE 游标名称 CURSOR FOR 查询语句; |
② 打开游标:
1 | OPEN 游标名称; |
③ 获取游标记录:
1 | FETCH 游标名称 INTO 变量[,变量]; |
④ 关闭游标:
1 | CLOSE 游标名称; |
(2) 案例:
1 | -- 游标 |
(3) 条件处理程序-handler
① 条件处理程序(Handler)可以用来定义在流程控制结构执行过程中遇到问题时相应的处理步骤。
② 语法:
1 | DECLARE handler action HANDLERFOR condition value l, condition value.... statement; |
③ 案例:
1 | create procedure p11(in uage int) |
存储函数:
1. 介绍:
存储函数是有返回值的存储过程,存储函数的参数只能是IN类型的。存储函数用的较少,能够使用存储函数的地方都可以用存储过程替换。
2. 语法:
1 | CREATE FUNCTION 存储函数名称([ 参数列表 ]) |
3. 案例:
1 | create function fun1(n int) |
触发器
1. 介绍
(1) 触发器是与表有关的数据库对象,指在 insert/update/delete 之前或之后,触发并执行触发器中定义的SQL语句集合。触发器的这种特性可以协助应用在数据库端确保数据的完整性,日志记录,数据校验等操作。
(2) 使用别名 OLD 和 NEW 来引用触发器中发生变化的记录内容,这与其他的数据库是相似的。现在触发器还只支持行级触发,不支持语句级触发。
| 触发器类型 | NEW 和 OLD |
|---|---|
| insert 型触发器 | NEW 表示将要或者已经新增的数据 |
| update 型触发器 | OLD 表示修改之前的数据,NEW 表示将要或已经修改后的数据 |
| delete 型触发器 | OLD 表示将要或者已经删除的数据 |
2. 语法:
(1) 创建:
1 | CREATE TRIGGER trigger name |
(2) 查看:
1 | SHOW TRIGGERS; |
(3) 删除:
1 | DROP TRIGGER [schema_name.]trigger_name; --如果没有指定 schema name,默认为当前数据库 |
(4) 案例:
1 | -- 插入数据触发器 |
锁
1. 介绍
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中,除传统的计算资源(CPU、RAM、I/0)的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说,锁对数据库而言显得尤其重要,也更加复杂。
2. 分类
MySQL中的锁,按照锁的粒度分,分为一下三类:
- 全局锁:锁定数据库中的所有表。
- 表级锁:每次操作锁住整张表。
- 行级锁:每次操作锁住对应的行数据。
全局锁
1. 介绍
① 全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将被阻塞。
② 其典型的使用场景是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性。
2. 演示图


3. 基本操作
① 使用全局锁:
1 | flush tables with read lock |
② 释放全局锁:
1 | unlock tables |
4. 特点:
数据库中加全局锁,是一个比较重的操作,存在以下问题:
- 如果在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆
- 如果在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志(binlog),会导致主从延迟。(该结构会在后续主从复制讲解)
5. 解决方法:
在InnoDB引擎中,我们可以在备份时加上参数 –single-transaction 参数来完成不加锁的一致性数据备份。
1 | mysqldump --single-transaction -uroot -p123456 itcast > itcast.sql |
注意:
这个方法只对 InnoDB 引擎有用(因为只有 InnoDB 支持事务);如果是 MyISAM 引擎,备份还是会锁表(MyISAM 不支持事务,没法搞 “快照”)。
表级锁
1. 介绍
每次操作锁住整张表。锁定粒度大,发生锁的冲突的概率最高,并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。对于表级锁,主要分为一下三类:
- 表锁
- 元数据锁(meta data lock,MDL)
- 意向锁
2. 表锁
① 对于表锁,分为两类:
- 表共享读锁(read lock)
- 表独占写锁(write lock)
读锁不会阻塞其他客户端的读,但是会阻塞写。写锁既会阻塞其他客户端的读,又会阻塞其他客户端的写。
② 语法:
1 | #表级别的共享锁,也就是读锁; |
3. 元数据锁
① MDL加锁过程是系统自动控制,无需显式使用,在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作。为了避免DML与DDL冲突,保证读写的正确性。
- 对一张表进行 CRUD(增删改查)操作时,加的是 MDL 读锁;
- 对一张表做结构变更操作的时候,加的是 MDL 写锁;
| 对应SQL | 锁类型 | 说明 |
|---|---|---|
| lock tables xxx read /write | SHARED_READ_ONLY/SHARED_NO_READ_WRITE | |
| select 、 select … lock in share mode | SHARED_READ | 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥 |
| insert 、update、delete、select …for update | SHARED_WRITE | 与SHARED_READ、SHARED_WRITE兼容,与EXCLUSIVE互斥 |
| alter table … | EXCLYSIVE | 与其他的MDL都互斥 |
② 查看元数据锁
1 | select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks; |
4. 意向锁
(1) 为什么需要意向锁?
若没有意向锁,加表锁时需要逐行检查表中所有记录是否有行锁(比如表有 10 万行,需检查 10 万次),效率极低。
(2) 核心类比
把数据库表比作「教室」,表中每一行比作「座位」:
- 行锁 = 占某个座位;
- 意向锁 = 教室门口贴的纸条(提示 “教室内已有座位被占用”);
- 表锁 = 锁整个教室(要求教室内无任何占座)。
(3) 意向共享锁和意向独占锁是表级锁,不会和行级的共享锁和独占锁发生冲突,而且意向锁之间也不会发生冲突,只会和**共享表锁(lock tables … read)和独占表锁(lock tables … write)**发生冲突
① 意向共享锁(IS):与表锁共享锁(read)兼容,与表锁排它锁(write)互斥。
② 意向排他锁(IX):与表锁共享锁(read)及排它锁(write)都互斥。
(4) 加锁方式:
1 | -- 意向共享锁:(先在表上加上意向共享锁,然后对读取的记录加共享锁) |
行级锁
行级锁,每次操作锁住对应的行数据。锁定粒度最小,发生锁冲突的概率最低,并发度最高。应用在InnoDB存储引擎中。
- 行锁(Record Lock):锁定单个行记录的锁,防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
- 间隙锁(GapLock):锁定索引记录间隙(不含该记录),确保索引记录间隙不变,防止其他事务在这个间隙进行insert,产生幻读。在RR隔离级别下都支持。
- 临键锁(Next-Key Lock):行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap。在RR隔离级别下支持。
1. Record Lock(行锁)
Record Lock 称为记录锁,锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分。
(1) InnoDB实现了以下两种类型的行锁:
- 共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排它锁。
- 排他锁(X):允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。
| S (共享锁) | X (排他锁) | |
|---|---|---|
| S (共享锁) | 兼容 | 冲突 |
| X (排他锁) | 冲突 | 冲突 |
(2) 行锁类型:
| SQL | 行锁类型 | 说明 |
|---|---|---|
| insert,update,delete … | 排他锁 | 自动加锁 |
| select | 不加任何锁 | |
| select … lock in share mode | 共享锁 | 需要手动select之后加上lock in share mode |
| select … for update | 排他锁 | 需要手动在select之后for update |
(3) 默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key锁进行搜索和索引扫描,以防止幻读。
- 针对唯一索引进行检索时,对已存在的记录进行等值匹配时,将会自动优化为行锁。
- InnoDB的行锁是针对于索引加的锁,不通过索引条件检索数据,那么!nnoDB将对表中的所有记录加锁,此时 就会升级为表锁。
(4) 查看意向锁及行锁的加锁情况:
1 | select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks; |
2. Gap Lock(间隙锁)
(1) Gap Lock 称为间隙锁,只存在于可重复读隔离级别,目的是为了解决可重复读隔离级别下幻读的现象。
(2) 假设,表中有一个范围 id 为(3,5)间隙锁,那么其他事务就无法插入 id = 4 这条记录了,这样就有效的防止幻读现象的发生。

间隙锁虽然存在 X 型间隙锁和 S 型间隙锁,但是并没有什么区别,间隙锁之间是兼容的,即两个事务可以同时持有包含共同间隙范围的间隙锁,并不存在互斥关系,因为间隙锁的目的是防止插入幻影记录而提出的。
3. Next-Key Lock(临键锁)
(1) Next-Key Lock 称为临键锁,是 Record Lock + Gap Lock 的组合,锁定一个范围,并且锁定记录本身。
(2) 假设,表中有一个范围 id 为(3,5] 的 next-key lock,那么其他事务即不能插入 id = 4 记录,也不能修改 id = 5 这条记录。

(3) 所以,next-key lock 既能保护该记录,又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。
4. 结论
默认情况下,InnODB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜索和索引扫描,以防止幻读。
- 索引上的等值查询(唯一索引),给不存在的记录加锁时,优化为间隙锁 。
- 索引上的等值查询(普通索引),向右遍历时最后一个值不满足查询需求时,next-keylock退化为间隙锁。
- 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。
InnoDB引擎
1. 逻辑存储结构

(1) 表空间(对应 ibd 文件)
MySQL 实例级的存储容器,一个 MySQL 实例可以对应多个表空间,用于存储表的记录、索引等数据。
(2) 段(Segment)
① 是表空间的下一级结构,用于管理多个区;
② 分类:
- 数据段(Leaf node segment):对应 B + 树的叶子节点
- 索引段(Non-leaf node segment):对应 B + 树的非叶子节点;
- 回滚段(Rollback segment):用于事务回滚相关的版本管理。
(3) 区(Extent)
表空间的单元结构,每个区的大小为 1MB,默认 InnoDB 页大小为 16KB,因此 1 个区包含 1MB ÷ 16KB = 64个连续的页。
(4) 页(Page)
① InnoDB 存储引擎**磁盘管理的最小单元,**每个页的大小默认 16KB;
② 为了保证页的物理连续性,InnoDB 存储引擎每次会从磁盘一次性申请 4-5 个区。
(5) 行
① InnoDB 的数据是按 “行” 为单位存放的;
② 行的隐藏列(事务相关):
trx_id:事务 ID,每次修改记录时,会将对应事务的 ID 存入trx_id隐藏列;roll_pointer(回滚指针):修改记录时,会把数据的旧版本写入 undo 日志;回滚指针相当于 “指针”,可通过它找到记录修改前的信息。
2. 整体架构

3. 内存架构

(1) Buffer Pool:
① 缓冲池是内存中的一个区域,它可以缓存磁盘上经常操作的真实数据,在执行增删改查操作时,先操作缓冲中的数据(若缓冲池没有数据,则从磁盘加载并缓存),然后以一定频率刷新到磁盘,从而减少磁盘 IO,加快处理速度。
② 缓冲池以 Page 为单位,采用链表数据结构管理 Page。根据状态,将 Page 分为三种类型:
- free page:空的 page,未被使用。
- clean page:被使用 page,数据没有被修改过。
- dirty page:脏页,被使用 page,数据被修改过,也就是缓冲与磁盘的数据产生了不一致。
(2) Change Buffer:
① 更改缓存(针对于非唯一二级索引使用),在执行 DML 语句时,如果该数据 Page 没有在 Buffer Pool 里,不会直接把磁盘进行操作,而会将变更暂存在更改缓存区 Change Buffer 中,在未来数据被读取时,再将数据合并并更新到 Buffer Pool,再将合并后的数据刷新到磁盘中。
② 与主键索引不同,二级索引通常是非唯一的,并且以相对随机的顺序插入二级索引,同样,删除和更新可能会影响索引中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量的随机 IO,有了 ChangeBuffer 之后,我们可以在缓存池中进行合并处理,减少磁盘 IO。
(3) Adaptive Hash Index:
① 自适应 hash 索引,用于优化对 Buffer Pool 数据的查询。InnoDB 存储引擎会监控对表上各索引页的查询,如果观察到 hash 索引可以提升速度,则建立 hash 索引,称之为自适应 hash 索引。
② 自适应哈希索引,无需人工干预,是系统根据情况自动完成。
(4) Log Buffer:
① 日志缓冲区,用来保存要写入到磁盘中的 log 日志数据(redo log、undo log)。默认大小为 16MB,日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务,增加日志缓冲区的大小可以节省磁盘 I/O。
② 参数:
- Innodb_log_buffer_size:缓冲区大小
- innodb_flush_log_at_trx_commit:日志刷新到磁盘时机
1: 日志在每次事务提交时写入并刷新到磁盘
0: 每秒将日志写入并刷新到磁盘一次
2: 日志在每次事务提交后写入,并每秒刷新到磁盘一次
4. 磁盘结构

(1) System Tablespace:
① 是更改缓冲区的存储区域;若表创建在该空间(而非单表 / 通用表空间),还会包含表、索引数据。(在 MySQL5.x 版本中还包含 InnoDB 数据字典、undolog 等)
② 参数:innodb_data_file_path
(2) File-Per-Table Tablespaces:
① 每个表的文件表空间包含单个 InnoDB 表的数据和索引,并存储在文件系统上的单个数据文件中。
② 参数:innodb_file_per_table
(3) General Tablespaces:通用表空间
① 创建通用表空间:
1 | CREATE TABLESPACE xxx ADD DATAFILE 'file_name' ENGINE = engine_name; |
② 对应表创建语句:
1 | CREATE TABLE xxx ... TABLESPACE ts_name; |
(4) Undo Tablespaces:
撤销表空间,MySQL 在实例初始化时会自动创建两个默认的 undo 表空间(初始大小 16MB),用于存储 undo log 日志。
(5) Temporary Tablespaces:
InnoDB 使用设备临时表空间和全局临时表空间,存储用户创建的临时表等数据。
(6) Doublewrite Buffer Files:
① 双写缓冲,InnoDB 引擎将数据页从 Buffer Pool 刷新到磁盘前,先将数据页写入双写缓冲文件中,便于系统异常时恢复数据。
② 示例文件:
#ib_16384.0.dblwr#ib_16384.1.dblwr
(7) Redo Log:
① 重做日志,是用来实现事务的持久性。该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log)。前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志中,用于在数据页写到磁盘时发生错误时,进行数据恢复使用。
② 以循环方式写入重做日志文件,涉及两个文件:
ib_logfile0ib_logfile1
5. 后台线程

6. 事务原理
(1) 事务:一组操作的集合,它是一个不可分割的工作单位,事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。
(2) 特征:
- 原子性(Atomicity):事务是不可分割的最小操作单元,要么全部成功,要么全部失败。
- 一致性(Consistency) :事务完成时,必须使所有的数据都保持一致状态。
- 隔离性(lsolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行。
- 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变就是永久的。
(3) 特性原理分类图:

7. redo log
(1) 重做日志,记录的是事务提交时数据页的物理修改,是用来实现事务的持久性。
(2) 该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中,用于在刷新脏页到磁盘,发生错误时,进行数据恢复使用。
(3) Buffer Pool在产生脏页数据的时候,会先将数据存储到 redo log buffer 再存储到 redo log 中进行磁盘持久化存储,在内存出现异常(比如突然断电)时,通过redo log中持久化的数据进行回滚。过程如下图:

(4) redo log 分为 2 部分:
- 内存里的「redo log 缓冲」:临时存一下修改记录(相当于 “草稿纸”);
- 磁盘里的「redo log 文件」:长期存修改记录(相当于 “正式笔记本”)。
(5) 工作流程像这样:
比如你修改了一条数据 → 先把 “我改了啥、怎么改的” 记到「redo log 缓冲」里 → 事务提交时,把缓冲里的记录写到「redo log 文件」里 → 之后数据库再慢慢把修改好的数据(存在内存缓存里的 “脏数据”)刷到磁盘。
要是中途突然断电:重启后,数据库会看「redo log 文件」里的记录,把没来得及刷到磁盘的修改,重新恢复出来。
Q:redo log 要写到磁盘,数据也要写磁盘,为什么要多此一举?
A:redo log 是 ”顺序写“,**磁盘处理起来特别快;**而直接写数据是 ”随机写“,得先找到数据在磁盘里的位置,再修改,速度很慢。
8. undo log
(1) 回滚日志,用于记录数据被修改前的信息,作用包含两个:提供回滚 和 MVCC(多版本并发控制)。
(2) undo log 和 redo log 记录物理日志不一样,它是逻辑日志。可以认为当 delete 一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当 update 一条记录时,它记录一条对应相反的 update 记录。当执行 rollback 时,就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。
(3) Undo log 销毁:undo log 在事务执行时产生,事务提交时,并不会立即删除undol0g,因为这些日志可能还用于 MVCC。
(4) Undo log 存储:undo log 采用段的方式进行管理和记录,存放在前面介绍的 rollback segment 回滚段中,内部包含1024个 undo log segment.
MVCC
1. 当前读:
读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select…lock in share mode(共享锁),select… for update、update、insert、delete(排他锁)都是一种当前读。
2. 快照读:
简单的select(不加锁)就是快照读,快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
- Read committed:每次select,都生成一个快照读。
- Repeatable Read:开启事务后第一个select语句才是快照读的地方。
- Serializable:快照读会退化为当前读。
3. MVCC:
全称 Multi-Version Concurrency Control,多版本并发控制。指维护一个数据的多个版本,使得读写操作没有冲突,快照读为 MVSQL 实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段、undo log日志、read View。
4. 三个隐藏字段

5. undo log
(1) 回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志。
(2) 当insert的时候,产生的undolog日志只在回滚时需要,在事务提交后,可被立即删除。
(3) 而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。
(4) 那么何时删除?
① 事务提交后:
- 对于
INSERT操作,事务提交后,undo log可以被立即删除,因为不再需要用于回滚。例如:你新增了一条 “订单记录”,事务提交后,既不需要回滚(回滚是删这条记录,但提交了就不用回滚了),也不会有其他事务需要读这条记录的 “旧版本”(因为它是刚新增的,没有更早的版本),所以 undo log 没用了,直接删。
**Q:**为什么说没有旧版本?旧版本不是没有插入之前的吗?
**A:**这里的旧版本指的是 **“这条新插入记录本身的旧版本” ,**不是 ”表在插入前的状态“,可以理解成行锁和表锁的关系。
- 对于
UPDATE和DELETE操作,undo log不会立即被删除,因为它们可能在后续的快照读取中被使用。例如:你把 “订单金额从 100 改成 200”,事务提交后,可能有其他事务需要看 “金额 100” 这个旧版本(比如查 5 分钟前的订单状态),这时候得靠 undo log 调出旧数据,所以它还能用,得留着。
② 快照读取结束:
- 当所有依赖于该undo log的快照读取操作结束后,undo log才会被删除。这意味着如果有一个事务正在进行快照读取,并且依赖于某个undo log,那么这个undo log会一直保留直到该事务结束。
(5) undo log 版本链

6. readview
(1) ReadView(读视图)是 快照读 SOL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id。
(2) ReadView中包含了四个核心字段:
| 字段 | 含义 |
|---|---|
| m_ids | 当前活跃的事务ID集合 |
| min_trx_id | 最小活跃事务ID |
| max_trx_id | 预分配事务ID,当前最大事务ID+1(因为事务ID是自增的) |
| creator_trx_id | ReadView创建者的事务ID(即 “当前要读数据的那个事务” 的 ID) |
(3) 版本链数据访问规则

① 规则 1:(trx_id = creator_trx_id → 能访问):
这里的creator_trx_id就是表格里的 “ReadView 创建者的事务 ID”—— 如果某数据版本的修改者 ID,和 “当前读数据的事务 ID” 一致,说明是自己改的,能访问。
② 规则 2:(trx_id < min_trx_id → 能访问):
min_trx_id是 “最小活跃事务 ID”—— 如果某数据版本的修改者 ID,比 “当前最小编号的活跃事务” 还小,说明这个修改事务早于所有活跃事务完成提交,能访问。
③ 规则 3:(trx_id > max_trx_id → 不能访问):
max_trx_id是 “预分配事务 ID(当前最大 ID+1)”—— 如果某数据版本的修改者 ID,比这个预分配 ID 还大,说明这个修改事务是在 ReadView 创建之后才启动的(事务 ID 自增),还没完成,不能访问。
④ 规则 4:(min_trx_id ≤ trx_id ≤ max_trx_id 且 trx_id 不在 m_ids 里 → 能访问):
min_trx_id/max_trx_id限定了 “当前活跃事务的 ID 范围”;m_ids是 “当前活跃的事务 ID 集合”—— 如果某数据版本的修改者 ID 在这个范围内,但不在活跃集合里,说明这个修改事务已经提交了(从活跃状态变成已完成),能访问。
(4) 原理分析(RC 级别)

之所以事务3,事务4都是活跃事务,是因为这个表格执行顺序是从上至下的,在事务5 第一次查询 id 为 30 的记录时,事务3 和 事务4 都没有结束。在事务5 第二次查询 id 为 30 的记录时,事务3 已经结束了
(5) 原理分析(RR 级别)

MySQL 管理
1. 系统数据库介绍
Mysql数据库安装完成后,自带了一下四个数据库,具体作用如下:
| 数据库 | 含义 |
|---|---|
| mysql | 存储MySQL服务器正常运行所需要的各种信息(时区、主从、用户、权限等) |
| information_schema | 提供了访问数据库元数据的各种表和视图,包含数据库、表、字段类型及访问权限等 |
| performance_schema | 为MySQL服务器运行时状态提供了一个底层监控功能,主要用于收集数据库服务器性能参数 |
| sys | 包含了一系列方便 DBA和开发人员利用 performance_schema性能数据库进行性能调优和诊断的视图 |
2. 常用工具
(1) mysql

(2) mysqladmin

(3) mysqlbinlog

(4) mysqlshow

(5) mysqldump

(6) mysqlimport / source

MySQL运维篇
日志
1. 错误日志
(1) 错误日志是 MySQL 中最重要的日志之一,它记录了当 mysqld 启动和停止时,以及服务器在运行过程中发生任何严重错误时的相关信息当数据库出现任何故障导致无法正常使用时,建议首先查看此日志。
(2) 该日志是默认开启的,默认存放目录 /var/log/,默认的日志文件名为 mysqld.log 。查看日志位置:
1 | show variables like '%log_error%' |
2. 二进制日志
(1) 二进制日志(BINLOG)记录了所有的 DDL(数据定义语言)语句和 DML(数据操纵语言)语句,但不包括数据查询(SELECT、SHOW)语句。
(2) 作用:
① 灾难时的数据恢复;
② MySQL的主从复制。
在MySQL8版本中,默认二进制日志是开启着的,涉及到的参数如下:
1 | show variables like '%log_bin%' |
(3) 日志格式
MySQL服务器中提供了多种格式来记录二进制记录,具体格式及特点如下:
| 日志格式 | 含义 |
|---|---|
| statement | 基于SQL语句的日志记录,记录的是SQL语句,对数据进行修改的SQL都会记录在日志文件中。 |
| row | 基于行的日志记录,记录的是每一行的数据变更。(默认) |
| mixed | 混合了STATEMENT和ROW两种格式,默认采用STATEMENT,在某些特殊情况下会自动切换为ROW进行记录。 |
查看参数方式:
1 | show variables like '%binlog_format%'; |
(4) 日志查看
由于日志是以二进制方式存储的,不能直接读取,需要通过二进制日志查询工具 mysqlbinlog 来查看,具体语法:
1 | mysqlbinlog[参数选项]logfilename |
(5) 日志删除
对于比较繁忙的业务系统,每天生成的binlog数据巨大,如果长时间不清除,将会占用大量磁盘空间。可以通过以下几种方式清理日志:
| 指令 | 含义 |
|---|---|
| reset master | 删除全部 binlog 日志,删除之后,日志编号,将从 binlog.000001重新开始 |
| purge master logs to ‘binlog.***’ | 删除 *** 编号之前的所有日志 |
| purge master logs before ‘yyyy-mm-dd hh24:mi:ss’ | 删除日志为”yyyy-mm-dd hh24:mi:ss”之前产生的所有日志 |
也可以在mysql的配置文件中配置二进制日志的过期时间,设置了之后,二进制日志过期会自动删除。
1 | show variables like '%binlog_expire_logs_seconds%' |
3. 查询日志
(1) 查询日志中记录了客户端的所有操作语句,而二进制日志不包含查询数据的SQL语句。默认情况下,查询日志是未开启的。如果需要开启查询日志,可以设置一下配置:
修改MySQL的配置文件 /etc/my.cnf 文件,添加如下内容:
1 | #该选项用来开启查询日志,可选值:0或者1;0代表关闭,1代表开启 |
4. 慢查询日志
(1) 慢查询日志记录了所有执行时间超过参数 long_query_time 设置值并且扫描记录数不小于 min_examined_row_limit的所有的SQL语句的日志,默认未开启。long_query_time 默认为 10 秒,最小为0,精度可以到微秒。
1 | #慢查询日志 |
(2) 默认情况下,不会记录管理语句,也不会记录不使用索引进行查找的查询。可以使用log_slow_admin_statements和更改此行为log_queries_not_using_indexes,如下所述。
1 | #记录执行较慢的管理语句 |
主从复制
1. 概述
(1) 主从复制是指将主数据库的 DDL 和 DML 操作通过二进制日志传到从库服务器中,然后在从库上对这些日志重新执行(也叫做重做),从而使得从库和主库的数据保持同步。
(2) MySQL 支持一台主库同时向多台从库进行复制,从库同时也可以作为其他服务器的主库,实现链式复制。
(3) MySQL 复制的优点主要包含以下三个方面:
① 主库出现问题,可以快速切换到从库提供服务。
② 实现读写分离,降低主库的访问压力。
③ 可以在从库中执行备份,以避免备份期间影响主服务器。
2. 原理

从上图来看,复制分成三步:
(1) Master 主库在事务提交时,会把数据变更记录在二进制日志文件 Binlog 中。
(2) 从库读取主库的二进制日志文件 Binlog,写入到从库的中继日志 Relay log。
(3) slave 重做中继日志中的事件,将改变反映它自己的数据。
3. 搭建

4. 主库配置
(1) 修改配置文件 /etc/my.cnf
1 | #mysql 服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,默认为1 |
(2) 重启 MySQL 服务器
1 | systemctl restart mysqld |
(3) 登录 mysql,创建远程连接的账号,并授予主从复制权限
1 | #创建itcast用户,并设置密码,该用户可在任意主机连接该MySQL服务 |
(4) 通过指令,查看二进制日志坐标
1 | show master status; |
字段含义说明:
file:从哪个日志文件开始推送日志文件
position:从哪个位置开始推送日志
binlog_ignore_db:指定不需要同步的数据库
5. 从库配置
(1) 修改配置文件 /etc/my.cnf
1 | #mysql服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,和主库不一样即可 |
(2) 重新启动 MySQL 服务
1 | systemctl restart mysqld |
(3) 登录 mysql,设置主库配置
1 | CHANGE REPLICATION SOURCE TO SOURCE_HOST='xxx', SOURCE_USER='xxx', SOURCE_PASSWORD='xxx', SOURCE_LOG_FILE='xxx', SOURCE_LOG_POS=xxx; |
上述是 8.0.23 中的语法。如果 mysql 是 8.0.23 之前的版本,执行如下 SQL:
1 | CHANGE MASTER TO MASTER_HOST='xxx.xxx.xxx.xxx', MASTER_USER='xxx', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=xxx; |
| 参数名 | 含义 | 8.0.23 之前 |
|---|---|---|
| SOURCE_HOST | 主库 IP 地址 | MASTER_HOST |
| SOURCE_USER | 连接主库的用户名 | MASTER_USER |
| SOURCE_PASSWORD | 连接主库的密码 | MASTER_PASSWORD |
| SOURCE_LOG_FILE | binlog 日志文件名 | MASTER_LOG_FILE |
| SOURCE_LOG_POS | binlog 日志文件位置 | MASTER_LOG_POS |
(4) 开启同步操作
1 | start replica ; #8.0.22之后 |
(5) 查看主从同步状态
1 | show replica status ; #8.0.22之后 |
6. 测试
(1) 在主库上创建数据库、表,并插入数据
1 | create database db01; |
(2) 在从库中查询数据,验证主从是否同步。
分库分表
1. 介绍
(1) 问题分析
随着互联网及移动互联网的发展,应用系统的数据量也是成指数式增长,若采用单数据库进行数据存储,存在以下性能瓶颈:
① I/O 瓶颈:热点数据太多,数据库缓存不足,产生大量磁盘 I/O,效率较低。请求数据太多,带宽不够,网络 I/O 瓶颈。
② CPU 瓶颈:排序、分组、连接查询、聚合统计等 SQL 会耗费大量的 CPU 资源,请求数太多,CPU 出现瓶颈。
分库分表的中心思想都是将数据分散存储,使得单一数据库 / 表的数据量变小来缓解单一数据库的性能问题,从而达到提升数据库性能的目的。
(2) 拆分策略

(3) 垂直拆分
① 垂直分库

以表为依据,根据业务将不同表拆分到不同库中。
特点:
- 每个库的表结构都不一样。
- 每个库的数据也不一样。
- 所有库的并集是全量数据。
② 垂直分表

以字段为依据,根据字段属性将不同字段拆分到不同表中。
特点:
- 每个表的结构都不一样。
- 每个表的数据也不一样,一般通过一列(主键 / 外键)关联。
- 所有表的并集是全量数据。
(4) 水平拆分
① 水平分库

以字段为依据,按照一定策略,将一个库的数据拆分到多个库中。
特点:
- 每个库的表结构都一样。
- 每个库的数据都不一样。
- 所有库的并集是全量数据。
② 水平分表

以字段为依据,按照一定策略,将一个表的数据拆分到多个表中。
特点:
- 每个表的表结构都一样。
- 每个表的数据都不一样。
- 所有表的并集是全量数据。
2. Mycat 入门
(1) 安装
Mycat 是采用 java 语言开发的开源的数据库中间件,支持 Windows 和 Linux 运行环境,下面介绍 Mycat 在 Linux 中的环境搭建,我们需要在准备好的服务器中安装如下软件。
- MySQL
- JDK
- Mycat
| 服务器 | 安装软件 | 说明 |
|---|---|---|
| 192.168.200.210 | JDK、Mycat | Mycat 中间件服务器 |
| 192.168.200.210 | MySQL | 分片服务器 |
| 192.168.200.213 | MySQL | 分片服务器 |
| 192.168.200.214 | MySQL | 分片服务器 |
(2) 概念介绍

(3) 需求
由于 tb_order 表中数据量很大,磁盘 IO 及容量都到达了瓶颈,现在需要对 tb_order 表进行数据分片,分为三个数据节点,每一个节点主机位于不同的服务器上,具体的结构,参考下图:

(4) 分片配置


编
(5) 启动服务
切换到 Mycat 的安装目录,执行如下指令,启动 Mycat:
1 | #启动 |
Mycat 启动之后,占用端口号 8066。
启动完毕之后,可以查看 logs 目录下的启动日志,查看 Mycat 是否启动完成。

(6) 分片测试
① 通过如下指令,就可以连接并操作 Mycat。
1 | mysql -h 192.168.200.210 -P 8066 -uroot -p123456 |
② 然后就可以在 Mycat 中创建表,并往结构中插入数据,查看数据在 MySQL 中的分布情况。
1 | CREATE TABLE TB_ORDER( |
3. MyCat 配置
(1) schema.xml
schema.xml作为MyCat中最重要的配置文件之一,涵盖了MyCat的逻辑库 、逻辑表 、分片规则、分片节点及数据源的配置。
主要包含以下三组标签:
- schema标签
- datanode标签
- datahost标签
① schema标签(第一行)
1 | <schema name="DB01" checkSQLschema="true" sqlMaxLimit="100" > |
schema 标签用于定义 MyCat 实例中的逻辑库,一个 MyCat 实例中,可以有多个逻辑库,可以通过 schema 标签来划分不同的逻辑库。
MyCat 中的逻辑库的概念,等同于 MySQL 中的 database 概念,需要操作某个逻辑库下的表时,也需要切换逻辑库 (use xxx)。
核心属性:
- name:指定自定义的逻辑库库名
- checkSQLschema:在 SQL 语句操作时指定了数据库名称,执行时是否自动去除;true:自动去除,false:不自动去除
- sqlMaxLimit:如果未指定 limit 进行查询,列表查询模式查询多少条记录
② table 标签
1 | <schema name="DB01" checkSQLschema="true" sqlMaxLimit="100" > |
table 标签定义了 MyCat 中逻辑库 schema 下的逻辑表,所有需要拆分的表都需要在 table 标签中定义。
核心属性:
- name:定义逻辑表表名,在该逻辑库下唯一
- dataNode:定义逻辑表所属的 dataNode,该属性需要与 dataNode 标签中 name 对应;多个 dataNode 逗号分隔
- rule:分片规则的名字,分片规则名字是在 rule.xml 中定义的
- primaryKey:逻辑表对应真实表的主键
- type:逻辑表的类型,目前逻辑表只有全局表和普通表,如果未配置,就是普通表;全局表,配置为 global
③ dataNode 标签
1 | <dataNode name="dn1" dataHost="dhost1" database="db01" /> |
dataNode 标签中定义了 MyCat 中的数据节点,也就是我们通常说的数据分片。一个 dataNode 标签就是一个独立的数据分片。
核心属性:
- name:定义数据节点名称
- dataHost:数据库实例主机名称,引用自 dataHost 标签中 name 属性
- database:定义分片所属数据库
④ dataHost 标签
1 | <dataHost name="dhost1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="jdbc"> |
核心属性:
- name:唯一标识,供上层标签使用
- maxCon/minCon:最大连接数 / 最小连接数
- balance:负载均衡策略,取值 0,1,2,3
- writeType:写操作分发方式(0:写操作转发到第一个 writeHost,第一个挂了,切换到第二个;1:写操作随机分发到配置的 writeHost)
- dbDriver:数据库驱动,支持 native、jdbc

(2) rule.xml
rule.xml 中定义所有分表的规则,在使用过程中可以灵活的使用分片算法,或者对同一个分片算法使用不同的参数,它让分片过程可配置化。主要包含两类标签:tableRule、function。

(3) server.xml
① system 标签
1 | <system> |
② user 标签

分库分表
1. 垂直拆分
(1) 场景

(2) 配置
1 | <schema name="SHOPPING" checkSQLschema="true" sqlMaxLimit="100" > |
说明:
schema 节点下关联多个 table 标签,不同 table 对应不同 dataNode:
① dn1 对应商品类表(如 tb_goods_base、tb_goods_cat 等)
② dn2 对应订单类表(如 tb_order_item、tb_order_master 等)
③ dn3 对应用户及地址类表(如 tb_user、tb_areas_provinces 等)
(3) 测试
① 在 mycat 的命令行中,通过 source 指令导入表结构及对应数据,查看数据分布情况:
1 | source /root/shopping_table.sql |
② 查询用户的收件人及收件人地址信息 (包含省、市、区):
1 | select ua.user_id,ua.contact,p.province,c.city,r.area,ua.address from tb_user_address ua,tb_areas_city c,tb_areas_provinces p,tb_areas_region r where ua.province_id = p.provinceid and ua.city_id = c.cityid and ua.town_id = r.areaid ; |
③ 查询每一笔订单及订单的收件地址信息 (包含省、市、区):
1 | SELECT o.order_id, p.payment,o.receiver,p.province,c.city,r.area FROM tb_order_master o,tb_areas_provinces p,tb_areas_city c,tb_areas_region r WHERE o.receiver_province = p.provinceid AND o.receiver_city = c.cityid AND o.receiver_region = r.areaid ; |
(4) 全局表配置
对于省、市、区 / 县表tb_areas_provinces, tb_areas_city, tb_areas_region,是属于数据字典表,在多个业务模块中都可能会遇到,可以将其设置为全局表,利于业务操作。
1 | <table name="tb_areas_provinces" dataNode="dn1,dn2,dn3" primaryKey="id" type="global"/> |
2. 水平拆分
(1) 场景
在业务系统中,有一张表 (日志表),业务系统每天都会产生大量的日志数据,单台服务器的数据存储及处理能力是有限的,可以对数据库表进行拆分。
(2) 配置
① shema.xml
1 | <schema name="ITCAST" checkSQLschema="true" sqlMaxLimit="100" > |
② server.xml
1 | <user name="root" defaultAccount="true"> |
(3) 测试
在 mycat 的命令行中,执行如下 SQL 建表、并插入数据,查看数据分布情况。
1 | CREATE TABLE tb_log ( |
3. 分片规则
(1) 范围分片
根据指定的字段及其配置的范围与数据节点的对应情况,来决定该数据属于哪一个分片。

说明:
- 0~5000000 → dataNode1
- 5000001~10000000 → dataNode2
- 10000001 及以上 → dataNode3

(2) 取模分片
根据指定的字段值与节点数量进行求模运算,根据运算结果,来决定该数据属于哪一个分片。

**说明:**通过id % 3的结果分配数据:
id%3=0→ dataNode1id%3=1→ dataNode2id%3=2→ dataNode3
(3) 一致性hash 分片
所谓一致性哈希,相同的哈希因子计算总是被划分到相同的分区表中,不会因为分区节点的增加而改变原来数据的分区位置。

① schema.xml
1 | <table name="tb_order" dataNode="dn4,dn5,dn6" rule="sharding-by-murmur" /> |
② rule.xml
1 | <tableRule name="sharding-by-murmur"> |
(4) 枚举分片
通过在配置文件中配置可能的枚举值,指定数据分布到不同数据库节点上。本规则适用于按照省份、性别、状态拆分数据等业务。

(5) 应用指定算法
运行阶段由应用自主决定路由到哪个分片,直接根据字符串(必须是数字)计算分片号。

说明:
- 00xxxx → 对应 dataNode1 的数据库
- 01xxxx → 对应 dataNode2 的数据库
- 02xxxx → 对应 dataNode3 的数据库

(6) 固定hash算法
该算法类似于十进制的求模运算,但是为二进制的操作,例如,取 id 的二进制低 10 位与1111111111进行位 & 运算。

说明:
① 任何一个十位的二进制与 1111111111(十位全1)进行与运算后的结果,结果就是这个十位二进制数本身。
② 原因是这个二进制数的每一位都是 1,因此在与运算中:
- 如果原数某一位是 1 → 1 & 1 = 1
- 如果原数某一位是 0 → 0 & 1 = 0
也就是说,它不会改变原数的任何一位,只是保留原数的所有位。
③ 举例验证:假设原数是 1010101010(十位):
1 | 1010101010 |

(7) 字符串hash解析
截取字符串中的指定位置的子字符串,进行hash算法,算出分片


运算示例:
以 “world” 为例:
- 截取子串:
world→ 取0:2对应 “wor” - 执行 hash 运算:得到结果 26629
- 计算分片:
26629 & (1024-1) = 5
(8) 按天分片

说明:
配置参数:begin:2022-01-01、end:2022-01-30、partitionDay:10
分片时间区间与 dataNode 对应:
2022-01-01 ~ 2022-01-10→ dataNode12022-01-11 ~ 2022-01-20→ dataNode22022-01-21 ~ 2022-01-30→ dataNode3

(9) 按月分片
使用场景为按月份来分片,每个自然月为一个分片

说明:
分片时间范围为 begin:2022-01-01 至 end:2022-03-31,数据按月份对应到不同 dataNode:
- dataNode1 对应数据:2022-01-10、2022-04-12(注:结束时间后会循环分片)
- dataNode2 对应数据:2022-02-20
- dataNode3 对应数据:2022-03-31

4. Mycat 管理及监控
(1) Mycat 原理

① select * from tb_user;
- 客户端把 SQL 发给 Mycat Server;
- Mycat 先解析 SQL,再做分片分析(按规则,这个 SQL 要查所有分片);
- 经路由分析,确定要访问右边 3 个数据库节点;
- 从 3 个节点取数据后,做分页、排序、聚合、结果合并;
- 把合并后的结果返回给客户端。
② select * from tb_user where status in(1,3) order by id;
- 客户端发 SQL 后,Mycat 解析出
status条件; - 分片分析 + 路由分析:只需要访问
status=1(dn1)和status=3(dn3)的数据库; - 从这 2 个节点取数据后,做排序处理 + 结果合并;
- 返回最终结果给客户端。
(2) Mycat 管理
① Mycat 默认开通 2 个端口,可在server.xml中修改:
- 8066 数据访问端口,用于执行 DML 和 DDL 操作。
- 9066 数据库管理端口,用于管理 Mycat 集群状态。
② 连接管理端口的命令:
1 | mysql -h 192.168.200.210 -P 9066 -uroot -p123456 |
③ Mycat 管理命令及含义:
| 命令 | 含义 |
|---|---|
| show @@help | 查看 Mycat 管理工具文档 |
| show @@version | 查看 Mycat 的版本 |
| reload @@config | 重新加载 Mycat 的配置文件 |
| show @@datasource | 查看 Mycat 的数据源信息 |
| show @@datanode | 查看 Mycat 现有的分片节点信息 |
| show @@threadpool | 查看 Mycat 的线程池信息 |
| show @@sql | 查看执行的 SQL |
| show @@sql.sum | 查看执行的 SQL 统计 |
读写分离
1. 介绍
(1) 读写分离,简单地说是把对数据库的读和写操作分开,对应不同的数据库服务器。主数据库提供写操作,从数据库提供读操作,这样能有效地减轻单台数据库的压力。
(2) 通过 MyCat 即可轻易实现上述功能,不仅可以支持 MySQL,也可以支持 Oracle 和 SQL Server。

说明:
① 应用程序连接 MyCat,MyCat 将insert/update/delete操作路由到writeHost对应的主库(mysql (m))
② 将select操作路由到readHost对应的从库(mysql (s))
③ 主库与从库之间通过主从复制(blog)同步数据
2. 一主一从读写分离
(1) 配置


Mycat 中balance参数的取值及含义说明表:
| 参数值 | 含义 |
|---|---|
| 0 | 不开启读写分离机制,所有读操作都发送到当前可用的 writeHost 上 |
| 1 | 全部的 readHost 与备用的 writeHost 都参与 select 语句的负载均衡(主要针对于双主双从模式) |
| 2 | 所有的读写操作都随机在 writeHost、readHost 上分发 |
| 3 | 所有的读请求随机分发到 writeHost 对应的 readHost 上执行,writeHost 不负担读压力 |
3. 双主双从
(1) 介绍
一个主机 Master1 用于处理所有写请求,它的从机 Slave1 和另一台主机 Master2 还有它的从机 Slave2 负责所有读请求。当 Master1 主机宕机后,Master2 主机负责写请求,Master1、Master2 互为备机。架构图如下:

说明:
① 应用程序连接 MyCat,MyCat 分发请求;
② mysql (m1)(Master1)复制数据到 mysql (s1)(Slave1),mysql (m2)(Master2)复制数据到 mysql (s2)(Slave2),同时 mysql (m1) 与 mysql (m2) 之间也存在复制关系,mysql (m1) 为主、mysql (m2) 为备
**Q:**主库不是负责写的吗?为什么 Master2 负责读了?
**A:双主双从中,Master1 是 “主用主库”:默认承担所有写请求;**而 Master2 是“备用主库”
- 平时(Master1 正常运行时),它不处理写请求,而是作为读节点来分担读压力(和 Slave1、Slave2 一起负责读请求);
- 只有当 Master1 宕机后,它才会切换为 “主库”,接手写请求。
(2) 准备工作
我们需要准备 5 台服务器,具体的服务器及软件安装情况如下:
| 编号 | IP | 预装软件 | 角色 |
|---|---|---|---|
| 1 | 192.168.200.210 | MyCat、MySQL | MyCat 中间件服务器 |
| 2 | 192.168.200.211 | MySQL | M1(Master1) |
| 3 | 192.168.200.212 | MySQL | S1(Slave1) |
| 4 | 192.168.200.213 | MySQL | M2(Master2) |
| 5 | 192.168.200.214 | MySQL | S2(Slave2) |
关闭以上所有服务器的防火墙:
systemctl stop firewalldsystemctl disable firewalld
(3) 搭建
① 主库配置(M1)
修改配置文件 /etc/my.cnf
1 | #mysql 服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,默认为1 |
重启 MySQL 服务器
1 | systemctl restart mysqld |
② 主库配置(M2)
修改配置文件 /etc/my.cnf
1 | #mysql 服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,默认为1 |
重启 MySQL 服务器
1 | systemctl restart mysqld |
③ 两台主库创建账户并授权(注:该操作需在 Master1、Master2 两台主库分别执行)
1 | # 创建itcast用户,并设置密码,该用户可在任意主机连接该MySQL服务 |
查看两台主库的二进制日志坐标
1 | show master status; |
④ 从库配置(S1)
修改配置文件 /etc/my.cnf
1 | #mysql 服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,默认为1 |
重启 MySQL 服务器
1 | systemctl restart mysqld |
⑤ 从库配置(S2)
修改配置文件 /etc/my.cnf
1 | #mysql 服务ID,保证整个集群环境中唯一,取值范围:1 - 2^32-1,默认为1 |
重启 MySQL 服务器
1 | systemctl restart mysqld |
⑥ 两台从库关联的从库
执行CHANGE MASTER TO命令,关联对应的主库(注意:slave1 对应 master1,slave2 对应 master2):
1 | CHANGE MASTER TO |
启动两台从库主从复制,查看从库状态
1 | # 启动主从复制 |
(4) 测试
分别在两台主库Master1、Master2上执行DDL、DML语句,查看涉及到的数据库服务器的数据同步情况。
1 | create database db01; |
4. 双主双从读写分离
(1) 配置


(2) 测试
① 登录MyCat,测试查询及更新操作,判定是否能够进行读写分离,以及读写分离的策略是否正确。
② 当主库挂掉一个之后,是否能够自动切换。




