MySQL
修改历史:
- 2025-07-01 修复了sql语句的代码快无法高亮的问题
MySQL-基础
数据库管理系统DBMS
MySQL数据模型
客户端->DBMS->多个数据库->多个二维表
SQL语句
DDL(Data Definition Language)数据定义语言(数据库、表、字段)
DML(Data Manipulation Language)数据操作语言
DQL(Data Query Language)数据查询语言
DCL(Data Control Language)数据控制语言,管理数据库用户,控制数据库的访问权限
DDL-数据定义
数据库操作
大类 | 语句 | 作用 |
---|---|---|
查询 | show databases | 查询所有数据库 |
select database() | 查询当前数据库 | |
创建 | create database [if not exists] 数据库名 | (如果不存在)创建一个数据库 |
使用 | use 数据库名; | 使用数据库 |
删除 | drop database [if exists] 数据库名 | 删除数据库 |
表操作-查询
语句 | 作用 |
---|---|
show tables; | 查询当前数据库所有表 |
desc 表名; | 查询表结构 |
show create table 表名; | 查询指定表的建表语句 |
表操作-创建
1 | create table 表名( |
关于约束:
约束 | 描述 | 关键字 |
---|---|---|
非空约束 | 限制字段值不能为null | not null |
唯一约束 | 保证字段所有数据唯一 | unique |
主键约束 | 主键是一行数据的唯一标识,非空且唯一 | primary key |
默认约束 | 字段未指定值则用默认值 | default |
外键约束 | 让两张表的数据建立连接 | foreign key |
字段数据类型
数值
类型 | 大小(byte) | 描述 |
---|---|---|
tinyint | 1 | 小整数值 |
smallint | 2 | 大整数值 |
mediumint | 3 | 大整数值 |
int | 4 | 大整数值 |
bigint | 8 | 极大整数值 |
float | 4 | 单精度浮点数 |
double | 8 | 双精度浮点数 |
decimal | 小数值(精确定点数) |
例如double,需使用double(整个数的长度,小数部分长度)
字符串
类型 | 描述 |
---|---|
char | 定长字符串 |
varchar | 变长字符串 |
tinyblob | 不超过255个字符的二进制数据 |
tinytext | 短文本字符串 |
blob | 二进制形式的长文本数据 |
text | 长文本数据 |
midiumblob | 二进制形式的中等长度文本数据 |
midiumtext | 中等长度文本数据 |
longblob | 二进制形式的极大文本数据 |
longtext | 极大文本数据 |
日期时间
大小 | 范围 | 格式 | 描述 | |
---|---|---|---|---|
date | 3 | 1000-01-01至9999-12-31 | YYYY-MM-DD | 日期值 |
time | 3 | -838:59:59至838:59:59 | HH:MM:SS | 时间值或持续时间 |
year | 1 | 1901至2155 | YYYY | 年份值 |
datatime | 8 | 1000-01-01 00:00:00至9999-12-31 23:59:59 | YYYY-MM-DD HH:MM:SS | 混合日期和时间值 |
timestamp | 4 | 1970-01-01 00:00:01至2038-01-19 03:14:07 | YYYY-MM-DD HH:MM:SS | 混合日期和时间值,时间戳 |
修改、删除表结构
语言可以不掌握,但是要会图形化操作
DML-数据操作
添加数据:
insert into 表名(字段1,字段2,……) values(值1,值2,……);
- 字符串应该和日期型数据应该包含在引号内
- 插入的数据大小,应该在字段的规定范围内
修改数据
update 表名 set 字段名1=值1,字段名2=值2,…[where 条件]
删除数据
delete from 表名 [where 条件]
DQL-数据查询
基本查询:
基本查询
select 字段列表 from 表名;
select * from 表名;(不建议在开发中使用这种方式,因为不直观)
起别名
select 字段 as ‘别名’ from 表名;as可省略
去重
select distinct 字段名称 from 表名;
条件查询:
select 字段列表 from 表名 where 条件列表;
比较运算符 | 功能 |
---|---|
> >= < <= = !=或<> | 比较 |
between…and … | 在某个范围之内(含最小值、最大值) |
in(…) | 在in之后的列表中的值,多选一 |
like 占位符 | 模糊匹配(_ 匹配单个字符,%匹配任意个字符) |
is null | 是null |
逻辑运算符 | 功能 |
---|---|
and或&& | 并且 |
or或|| | 或 |
not或! | 非 |
例子:
1 | select * from emp where name ='初音未来'; |
聚合函数:
select 聚合函数(字段列表) from 表名;
1 | -- 聚合函数 |
分组查询:
select 字段列表 from 表名 [where 条件] group by 分组字段名 [having 分组后过滤条件];
where与having区别
- 执行时间不同:where是分组之前进行过滤,不满足where条件,不参与分组;而having是分组之后对结果进行过滤;
- 判断条件不同:where不能对聚合函数进行判断,而having可以。
执行顺序:where > 聚合函数 > having
分组之后,查询的字段一般为聚合函数和分组字段,查询其他的字段毫无意义
1 | -- 根据性别分组,统计男性员工和女性员工的数量 |
排序查询:
select 字段列表 from 表名 order by 字段1 排序方式,字段2 排序方式;
排序方式:
ASC:升序(默认值)
DESC:降序
如果多字段排序,当第一个字段值相同的时候,才会根据第二个字段进行排序
分页查询:
select 字段列表 from 表名 limit 起始索引,查询记录数;
- 起始索引从0开始,起始索引=(查询页码-1)*每页显示记录数;
- 分页查询是数据库的方言,不同的数据库有不同的实现,MySQL是limit;
- 如果查询的是第一页数据,起始索引可以省略,直接简写为limit 10。
顺序
- 编写顺序:select>from>where>group by>order by>limit
- 执行顺序:from>where>group by>select>order by>limit
DCL-数据控制
管理用户:
1 | -- 查询用户 |
权限控制:
1 | -- 查询权限 |
- 多个权限之间,用逗号分隔;
- 授权时,数据库名和表名可以使用*进行通配,代表所有。
函数
字符串函数
concat(s1,s2,s3,…,sn)字符串拼接
lower(str)转大写
upper(str)转小写
lpad(str,n,pad)用pad左填充
rpad(str,n,pad)用pad右填充
trim(str)去除头部和尾部的空格
substring(str,start,len)截取字符串,索引从1开始
数值函数
ceil向上取整
floor向下取整
mod(x,y)求x/y的模
rand0~1之间的随机数
round(x,y)对x四舍五入后保留y位小数
案例:
1 | -- 产生一个6位数的随机验证码 |
日期函数
curdate()返回当前的日期
curtime()返回当前的时间
now()返回当前的日期和时间
year(date)返回日期的年份
month(date)返回日期的月份
day(date)返回日期的天数
date_add(date,interval expr type)返回一个推移指定时间长度后的日期
1 | select date_add(now(),interval 70 day); |
datediff(date1,date2)求取两个日期之间的天数,前边减后边的
流程函数
if(value,t,f)如果value为true,返回t,为false则返回f
ifnull()如果第一个值为null,则返回第二个值;如果第一个值非null,则返回第一个值
case when [value1] then [res1]… else [default] end如果value1为true,返回res1,…否则返回default
case [expr] when [val1] then [res1]… else [default] end如果expr的值为val1则返回res1,…否则返回default
约束
约束-概述
约束 | 描述 | 关键字 |
---|---|---|
非空约束 | 限制字段值不能为null | not null |
唯一约束 | 保证字段所有数据唯一 | unique |
主键约束 | 主键是一行数据的唯一标识,非空且唯一 | primary key |
默认约束 | 字段未指定值则用默认值 | default |
检查约束(8.0.16版本之后) | 保证字段值满足某一个条件 | check |
外键约束 | 让两张表的数据建立连接 | foreign key |
约束-外键约束
外键约束是让两张表之间的数据建立连接,从而保证数据的一致性。
语法
1 | -- 方法一 |
示例:
1 | -- 添加外键 |
外键删除更新行为
行为 | 说明 |
---|---|
no action | 当在父表中删除/更新对应记录时,首先检查该记录中是否有对应外键,如果有则不允许更改 |
restrict | 当在父表中删除/更新对应记录时,首先检查该记录中是否有对应外键,如果有则不允许更改 |
cascade | 当在父表中删除/更新对应记录时,首先检查该记录中是否有对应外键,如果有,则也删除/更新外键在子表中的记录 |
set null | 当在父表中删除对应记录时,首先检查该记录中是否有对应外键,如果有则设置为null(前提是允许为null) |
set default | 父表有变更时,子表将外键设置成一个默认的值(Innodb不支持) |
1 | alter table 表名 add constraint 外键名称 foreign key(外键字段) references 主表(主表列名) on update cascade on delete cascade; |
多表查询
多表关系
一对多
通常在多的一方添加外键,关联到一的一方的主键
多对多
建立第三方中间表,中间表至少包含两个外键,分别关联两方主键
一对一
通常用于单表查询,或者将其拆分,并在任意一方加入外键来关联。注意在外键中添加unique约束以保证一对一
连接查询
内连接
隐式内连接:select 字段列表 from 表1,表2 where 条件…;
显示内连接:select 字段列表 from 表1 [inner] join 表2 on 连接条件…;
1 | -- 隐式内连接 |
- 内连接查询的是两张表交集的部分
外连接
左外连接
select 字段列表 from 表1 left [outer] join 表2 on 条件…;
相当于查询表1(左表)的所有数据包括交集部分的数据
右外连接
select 字段列表 from 表1 right [outer] join 表2 on 条件…;
相当于查询表2(右表)的所有数据包括交集部分的数据
1 | -- 左外连接 |
常用左外连接实现
自连接
自连接查询使用内连接查询和外连接查询均可,重点是要给一张表起两个不同的别名
内连接查询(例)
select 字段列表 from 表A 别名A join 表 A 别名B on 条件…;
外连接查询(例)
select 字段列表 from 表A 别名A left join 表 A 别名B on 条件…;
联合查询
对于联合查询实际上就是将多次查询的结果合并起来,形成一个新的查询结果集,要使用到关键字union,union all。
语法:
1 | select 字段列表 from 表A… |
- 对于联合查询的多张表的列数和字段类型需要保持一致
- union all会将全部的数据直接贴合在一起,union会对合并之后的数据去重
子查询
标量子查询
子查询的结果是单个的值,就称为标量子查询
例如如下的需求,查询某某部门的所有员工信息
1 | -- 分步查询 |
列子查询
查询的结果为一列多行,就称为列子查询
常用的操作符
操作符 | 描述 |
---|---|
in | 在指定的集合范围之内,多选一 |
not in | 不在指定的集合范围之内 |
any | 子查询返回的列表中,有一个满足即可 |
some | 等同于any |
all | 子查询返回的列表的所有值必须满足 |
行子查询
查询的结果为一行多列,就称为列子查询
1 | -- 查询与“张无忌”的薪资及直属领导相同的员工信息 |
表子查询
查询的结果为多行多列,就称为表子查询。通常将表子查询的结果作为一个新的表进行多表查询。
1 | -- 查询与“鹿杖客”,“宋远桥”的职位和薪资相同的员工信息 |
事务
事务是一组操作的集合,这组操作,要么全部执行成功,要么全部执行失败
事务操作
第一种方式
- 查看/设置事务提交方式
select @@autocommit;
set @@autocommit=1; - 提交事务
commit; - 回归事务
rollback;
第二种方式
- 开启事务
start transaction或begin; - 提交事务
commit; - 回归事务
rollback;
事务的四大特性ACID
原子性:一个事务必须被视为一个不可分割的最小工作单元,整个事务中的所有操作要么全部提交成功,要么
全部失败回滚
一致性:数据库总是从一个一致性的状态转换到另一个一致性的状态
隔离性:数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行
持久性:一旦事务提交,则其所做的修改会永久保存到数据库
并发事务问题
问题 | 描述 |
---|---|
脏读 | 一个事务读到另一个事物还没有提交的数据 |
不可重复读 | 一个事务先后读取同一条记录,但两次读取的数据不同 |
幻读 | 一个事务按条件查询数据时,没有对应的数据行,但是在插入数据时,又发现这行数据已经存在 |
事务隔离级别
事务的隔离级别就是来解决并发事务问题的,下表表示解决情况。√表示未解决,×表示解决
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
Read uncommitted | √ | √ | √ |
Read committed | × | √ | √ |
Repeatable Read(默认) | × | × | √ |
Serializable | × | × | × |
查看事务的隔离级别
select @@transaction_isolation;
设置事务的隔离级别
set [global/session] transaction isolation level [隔离级别];
MySQL-进阶
存储引擎
MySQL体系结构
- 连接层
- 服务层
- 引擎层
- 存储层
简介
存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型
创建表时指定存储引擎:
1 | create table 表名( |
存储引擎的特点和选择
特点
-
InnoDB:
-
MySQL目前默认的存储引擎;
-
支持事务、外键、行级锁;
-
默认每张表对应与磁盘中的一个.ibd文件。
-
InnoDB的逻辑存储结构:在InnoDB的逻辑存储结构中,Page是操作的最小单元,Extent的大小固定为1M,Page大小固定为16K
-
MyISAM:
- MySQL早期的默认存储引擎;
- 不支持事务、外键,支持表锁不支持行锁,访问速度快;
- 文件:sdi:存储表结构的信息,MYD:存储数据,MYI:存储索引
-
MEMORY:
- 数据存放在内存中,由于受到硬件的问题、断电问题的影响,只能将这些表作为临时表或缓存使用
- 内存存放、hash索引(默认)
- .sdi文件:存储表结构的信息
存储引擎的选择:
-
InnoDB:是MySQL的默认存储引擎,支持事务、外键。如果应用对事务的完整性又比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包含很多的更新、删除操作,那么InnoDB存储引擎是比较合适的选择。
-
MyISAM:如果应用是以读取和插入为主,很少有更新、删除操作,并且对事务的完整性、并发性要求不是很高,那么选择这个存储引擎比较合适。
-
MEMORY:将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。MEMORY的缺陷就是对表的大小有限制,太大的表无法缓存在内存中,而且无法保证数据的安全性。
说是这么说,但是实际上主要用的就是InnoDB了,MyISAM的使用场景基本被nosql系列的数据库取代了,而MEMORY的场景被Redis取代了。
索引
概述
索引(index)本质上一种数据结构,是为了帮助数据库高效获取数据。
索引的优势:提高数据检索的效率,降低数据库的IO成本;通过索引列对数据进行排序,降低数据排序的成本,降低CPU的消耗。
索引的劣势:占用空间;降低了更新表操作insert、update、delete的效率
索引大大提高了查询效率,却也降低了insert、update、delete的效率,不过一般主要业务都是查询,所以瑕不掩瑜。
索引的结构
B+Tree索引:
MySQL常用(默认)的结构就是B+Tree(多路平衡搜索树)
- 每一个节点,可以存储多个key
- 所有的数据存储在叶子节点,非叶子节点仅用于索引数据
- 叶子节点形成了一颗双向链表,便于数据的排序及区间范围查询
这种结构就像一个矮胖的树,避免了二叉树容易层级过深的问题。
Hash索引:
Hash索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中。
如果两个(或多个)键值,映射到一个相同的键位,他们就产生了hash冲突(也称hash碰撞),可以通过链表来解决。
特点
- Hash索引只能用于对等比较(=,in),不支持范围查询(between,>,<,…)
- 无法利用索引完成排序操作
- 查询效率高,通常只需要一次检索就可以了,效率通常高于B+Tree索引
存储引擎支持
在MySQL中,支持hash索引的是MEMORY引擎,而InnoDB中具有自适应hash功能,hash索引是存储引擎根据B+Tree索引在指定条件下自动构建的。
思考:为什么InnoDB采用B+Tree索引?
- 相对于二叉树,层级更少,搜索效率更高
- 对于B-Tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储的键值减少,指针跟着减少,要同样保存大量的数据,只能增加树的高度,导致性能降低
- 相对于hash索引,hash索引不支持范围匹配及排序操作而B+Tree支持
其他的还有R-tree空间索引、Full-text全文索引。之后如果没有特别说明,索引都是指B+Tree索引
索引的分类
分类 | 含义 | 特点 | 关键字 |
---|---|---|---|
主键索引 | 针对于表中主键创建的索引 | 默认自动创建,只能有一个 | PRIMARY |
唯一索引 | 避免同一个表中某数据列中的值重复 | 可以有多个 | UNIQUE |
常规索引 | 快速定位特定数据 | 可以有多个 | |
全文索引 | 查找文本中的关键词,而不是比较索引中的值 | 可以有多个 | FULLTEXT |
在InnoDB存储引擎中,根据索引的存储形式,又可以分为以下两种:
聚集索引(Clustered Index)
- 将数据存储与索引放到了一块,索引结构的叶子节点保存了行数据
- 必须有,而且只有一个
二级索引(Secondary Index)
- 将数据与索引分开存储,索引结构的叶子节点关联的是对应的主键
- 可以存在多个
聚集索引的选取规则:
- 如果存在主键,主键索引就是聚集索引
- 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引
- 如果没有主键也没有合适的唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索引
结构如图所示:
有趣的问题:InnoDB的主键索引的B+Tree高度为多高?
假设,一行的数据为1K,那么一页(16K),就能存放16行这样的数据。InnoDB的指针占用6个字节的空间,主键类型如果为bigint,就占用8个字节的空间。
先算出一页中有多少个主键,设为x,则$x*8+(n+1)6=161024$,得x约为1170,那么就有1171个指针
如果树的高度为2:
那么存放数据有:$1171*16=18736$
如果树的高度为3:
那么存放的数据有:$1171^2*16=21939856$
索引的语法
- 创建索引
create [unique] index 索引名 on 表名(字段名,…);
- 查看索引
show index from 表名
- 删除索引
drop index 索引名 on 表名;
- 建表时如果添加了主键约束,那么就会自动创建主键索引,是性能最高的
- 建表时添加唯一约束,本质就是添加了唯一索引
SQL性能分析
SQL执行频率
通过如下指令,可以查看当前数据库的Insert、update、delete、select的访问频次
show global status like 'Com_______'
慢查询日志
慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认10秒)的所有SQL语句的日志。
MySQL的慢查询日志默认没有开启,需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息
1 | #开启MySQL慢查询日志开关 |
慢日志文件记录在/var/lib/mysql/localhost-slow.log
profile详情
show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通过have_profiling参数,能够看到当前MySQL是否支持profile操作:
SELECT @@have_profiling;
默认profiling是关闭的,可以通过set语句在session/global级别开启profiling:
SET profiling = 1;
执行一系列的业务SQL操作,然后通过以下指令可以查看指令的执行耗时
1 | #查看每一条SQL的耗时基本情况 |
explain执行计划
EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
语法:
直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;
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_keys
显示可能应用在这张表上的索引,一个或多个
➢ key
实际使用的索引,如果为NULL,则没有使用索引。
➢ key_len
表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下,长度越短越好。
➢ rows
MySQL认为必须要执行查询的行数,在innodb引擎的表中,是一个估计值,可能并不总是准确的。
➢ filtered
表示返回结果的行数占需读取行数的百分比,filtered 的值越大越好。
加粗的是需要重点关注的
索引的使用
最左前缀法则
如果索引了多列(联合索引),要遵守最左前缀法则。最左前缀法则指查询从索引最左列开始,并且不跳过索引中的列。如果跳跃了某一列,索引将部分失效(后面的字段索引失效)
范围查询
联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效
因此,在业务允许的范围内,尽量使用>=,<=这样的范围查询
索引列运算
不要在索引列上进行运算操作,索引将失效。
字符串不加引号
字符串类型字段使用时,不加引号,索引将失效。
模糊查询
如果仅仅是尾部模糊匹配,索引不会失效。如果是头部模糊匹配,索引失效。
因此在大数据量的情况下,要尽量避免头部模糊匹配的情况。
or连接的条件
用or分割开的条件,如果or前的条件中的列有索引,而后边的列没有索引,那么涉及的索引都不会用到。
解决办法:针对没有索引的列添加索引即可。
数据分布影响
如果MySQL评估使用索引比全表更慢,则不使用索引。
SQL提示
SQL提示,是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化的目的。
指令:
use index:
explain select * from 表名 use index(索引名字) where profession = ‘软件工程’
ignore index:
explain select * from 表名 ignore index(索引名字) where profession = ‘软件工程’
force index:
explain select * from 表名 force index(索引名字) where profession = ‘软件工程’
覆盖索引
尽量使用覆盖索引(查询使用了索引,并且需要返回的列,在该索引中已经能够全部找到),减少select *。
- 关于Extra的参数:
using index condition:查找使用了索引,但是需要回表查询数据
using where;using index:查找使用了索引,但是需要的数据在索引列中能够找到,所以不需要回表查询数据
所以后者的性能更高
- SQL优化问题:一张表,有四个字段(id,username,password,status)由于数据量大,需要对以下SQL语句进行优化,如何才是最优方案?
select id,username,password from tb_user where username='itcast'
- 答:需对username和password两个字段创建联合索引
前缀索引
当字段类型是字符串(varchar、text等)时,有时候需要索引很长的字符串,这会让索引变得很大,查询时,浪费大量的磁盘IO,影响查询效率。此时可以只将字符串的一部分前缀建立索引,这样就可以大大节约索引空间,从而提高索引效率。
- 语法
create index idx_xxx on table_name(column(n))
- 前缀长度
可以根据索引的选择性来决定,而选择性是指不重复的索引值(基数)和数据表的记录总数的比值,索引选择性越高则查询的效率越高,唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的。
select count(distinct email)/count(*) from tb_user;
select count(distinct substring(email,1,5))/count(*) from tb_user;
前缀索引的查询流程
单列索引与联合索引
单列索引:即一个索引只包含单个列
联合索引:即一个索引包含了多个列
在业务场景中,如果存在多个查询条件,考虑针对查询字段建立索引时,建议使用联合索引,而非单列索引。
例如:
- 单列索引情况:
explain select id,phone,name from tb_user where phone = '1111111323' and name ='xxx'
多条件联合查询时,MySQL优化器会评估哪个字段的索引效率更高,会选择该索引完成本次查询。
- 联合索引情况:
create unique index idx_phone_name on tb_user(phone,name)
由于创建的是联合索引,索引字段列表的顺序会有影响,参见最左前缀法则。
索引设计原则
- 针对于数据量较大,且查询比较频繁的表建立索引。 (几百万条)
- 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引。
- 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高。
- 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引。
- 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间,避免回表,提高查询效率。
- 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价也就越大,会影响增删改的效率。
- 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时,它可以更好地确定哪个索引最有效地用于查询。
SQL优化
插入数据
insert优化
-
批量插入
insert into tb_test values(1,'Tom),(2,'Cat)...
-
手动提交事务
1
2
3
4start transaction;
insert into tb_test values(1,'Tom),(2,'Cat')...;
...
commit; -
主键顺序插入
大批量数据插入
如果一次性需要插入大量数据,使用insert语句插入性能较低,此时可以使用MySQL数据库提供的load指令进行插入。操作如下:
1 | #客户端连接上服务器时,加上参数 —local-infile |
主键优化
数据组织方式
在InnoDB存储引擎中,表数据都是根据主键顺序组织存放的,这种存储方式的表称为索引组织表(index organized table IOT)。
页分裂
页可以为空,也可以填充一半,也可以填充100%。每个页包含了2-N行数据(如果一行数据太大,会行溢出),根据主键排列。
页合并
当删除一行记录时,实际上记录没有被物理删除,只是被标记(flaged)为删除并且它的空间变得允许被其他记录声明使用。
当页中删除的记录达到MERGE_THRESHOLD(默认为页的50%),InnoDB会开始寻找最靠近的页(左或右)看看是否可以将两个页合并以优化空间使用。
主键设计原则
- 满足业务需求的情况下,尽量降低主键的长度。
- 插入数据时,尽量选择顺序插入,选择使用AUTO_INCREMENT自增主键。
- 尽量不要使用UUID做主键或者是其他自然主键,如身份证号。
- 业务操作时,避免对主键的修改。
order by优化
-
Using filesort : 通过表的索引或全表扫描,读取满足条件的数据行,然后在排序缓冲区sort buffer中完成排序操作,所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。
-
Using index : 通过有序索引顺序扫描直接返回有序数据,这种情况即为 using index,不需要额外排序,操作效率高。
创建索引时指定升降序的指令:
create index idx_user_age_phone_aa on tb_user(age asc/desc, phone asc/desc);
如果没有指定,默认为降序。
总结
- 根据排序字段建立合适的索引,多字段排序时,也遵循最左前缀法则。
- 尽量使用覆盖索引。
- 多字段排序,一个升序一个降序,此时需要注意联合索引在创建时的规则(ASC/DESC)。
- 如果不可避免的出现filesort,大数据量排序时,可以适当增大排序缓冲区大小 sort_buffer_size(默认256k)。
group by优化
总结
- 在分组操作时,可以通过索引来提高效率。
- 分组操作时,索引的使用也是满足最左前缀法则的。
limit优化
一个常见的问题就是当limit的起始索引非常大时,此时MySQL需要排序起始索引前的记录,仅仅返回起始索引后的部分记录,其他记录废弃,查询排序的代价非常大。
优化思路:
一般分页查询时,通过创建覆盖索引能够比较好地提高性能,可以通过覆盖索引加子查询的形式进行优化。
count优化
对比MyISAM和InnoDB:
- MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count(*) 的时候会直接返回这个数,效率很高;
- InnoDB 引擎就麻烦了,它执行 count(*) 的时候,需要把数据一行一行地从引擎里面读出来,然后累积计数。
count的几种用法
- count是一个聚合函数,对于结果的返回集,一行行地判断,如果count函数的参数不是null,累计值就加1,否则不加,最后返回累计值。
- 用法:count(*),count(主键)、count(字段)、count(1)
几种用法的对比
count(主键)
InnoDB 引擎会遍历整张表,把每一行的主键id值都取出来,返回给服务层。服务层拿到主键后,直接按行进行累加(主键不可能为null)。
count(字段)
没有not null约束:InnoDB引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,服务层判断是否为null,不为null,计数累加。
有not null约束:InnoDB引擎会遍历整张表把每一行的字段值都取出来,返回给服务层,直接按行进行累加。
count(1)
InnoDB引擎遍历整张表,但不取值。服务层对于返回的每一行,放一个数字"1"进去,直接按行进行累加。
count(*)
InnoDB引擎并不会把全部字段取出来,而是专门做了优化,不取值,服务层直接按行进行累加。
按照效率排序的话,count(字段) < count(主键id) < count(1) ≈ count( * ),所以尽量使用count( * )。
update优化
InnoDB的行锁是针对索引加的锁,不是针对记录加的锁,并且该索引不能失效,否则会从行锁升级为表锁,导致并发性能的降低。
存储对象
视图
视图(View)是一种虚拟存在的表。视图中的数据并不在数据库中实际存在,行和列数据来自定义视图的查询中使用的表,并且是在使用视图时动态生成的。
通俗的讲,视图只保存了查询的SQL逻辑,不保存查询结果。所以我们在创建视图的时候,主要的工作就落在创建这条SQL查询语句上。
基本语法
-
创建视图
CREATE [OR REPLACE] VIEW 视图名称(列名列表) AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION]
-
查询视图
查看创建视图语句:SHOW CREATE VIEW 视图名称;
查看视图数据:SELECT * FROM 视图名称……;
-
修改视图
方式一:CREATE [OR REPLACE] VIEW 视图名称(列名列表) AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION]
方式二:ALTER VIEW 视图名称(列名列表) AS SELECT语句 [WITH[CASCADED | LOCAL] CHECK OPTION]
-
删除视图
DROP VIEW [IF EXISTS] 视图名称 [视图名称] …
视图的检查选项
当使用WITH CHECK OPTION子句创建视图时,MySQL会通过视图检查正在更改的每个行(如插入、更新、删除),以确保其符合视图的定义。MySQL允许基于另一个视图创建视图,并会检查依赖视图中的规则以保持一致性。为了确定检查的范围,MySQL提供了两个选项:CASCADED 和 LOCAL,默认值为 CASCADED。
- cascaded
1 | create view v1 as select id, name from student where id <= 20; |
说明:
- CASCADED选项会级联检查所有底层视图的条件,可以认为在依赖的视图v1上也添加了with cascaded check option
- 在示例中,v2视图会同时检查v1和v2自身的条件
- v3视图由于没有指定WITH CHECK OPTION,不会检查自身的条件,但是会检查v1和v2的条件
- local
使用local,会递归地去检查依赖的视图是否要进行检查,如果依赖的视图有with check option则也要进行检查。
视图的更新
-
视图的更新要求视图中的行与基础表中的行之间存在一对一的关系。
-
如果视图包含以下任何一项,则该视图不可更新:
-
聚合函数或窗口函数(如 SUM()、MIN()、MAX()、COUNT() 等)
-
DISTINCT
-
GROUP BY
-
HAVING
-
UNION 或 UNION ALL
-
视图的作用
- 简单
- 视图可以简化用户对数据的理解和操作。
- 常用的查询可以定义为视图,避免用户每次操作时重复指定全部条件。
- 安全
- 数据库可以授权,但无法精确到特定行或列。
- 通过视图,用户只能查询和修改他们被允许访问的数据。
- 数据独立
- 视图可帮助用户屏蔽真实表结构变化带来的影响。
存储过程
介绍
存储过程(procedure)是事先经过编译并存储在数据库中的一段SQL语句的集合,调用存储过程可以简化应用开发人员的很多工作,减少数据在数据库和应用服务器之间的传输,对于提高数据处理的效率是有好处的。
存储过程思想上很简单,就是数据库SQL语言层面的代码封装与重用。
特点
- 封装,复用
- 可以接收参数,也可以返回数据
- 减少网络交互,效率提升
基本语法
创建
1 | create procedure 存储过程名称([参数列表]) |
调用
1 | call 存储过程名称(); |
查看
1 | -- 查询指定数据库的存储过程及状态信息 |
删除
1 | drop procedure if exists 存储过程名字; |
注意:在命令行中创建存储过程时,需要通过关键字delimiter指定SQL语句的结束符。
格式就是delimiter 指定结束符;
变量
系统变量
MySQL服务器提供,不是用户定义的,属于服务器层面。分为全局变量(GLOBAL)、会话变量(SESSION)。
- 查看系统变量
1 | show [session|global] variables;-- 查看所有系统变量 |
- 设置系统变量
1 | set [session|global] 系统变量名 = 值; |
注意:如果没有指定session/global,默认是session,会话变量。
MySQL服务重启后,所设置的全局参数会失效,要想不失效,可以在/etc/my.cnf中配置。
用户定义变量
用户根据需要自己定义的变量,用户变量不用提前声明在用的时候用“@变量名”使用就可以。其作用域为当前连接。
- 赋值
1 | -- 可以使用=也可以使用:=,推荐使用:= |
- 使用
1 | select @var_name; |
注意:用户定义的变量无需对其进行声明或初始化,只不过获取到的值为NULL。
局部变量
根据需要定义的在局部生效的变量,访问之前,需要使用declare声明。可用作存储过程内的局部变量和输入参数,局部变量的范围是在其内声明的begin…end块。
- 声明
1 | declare 变量名 变量类型[default ...]; |
- 赋值
1 | set 变量名 = 值; |
if判断
- 语法
1 | if 条件1 then |
参数
类型 | 含义 | 备注 |
---|---|---|
IN | 作为输入参数,调用时需要传入值 | 默认类型 |
OUT | 作为输出参数,可作为返回值 | |
INOUT | 既可作输入参数,也可作输出参数 |
- 用法
1 | create procedure 存储过程名称([in/out/inout 参数名称 参数类型]) |
case
语法一
1 | CASE case_value |
语法二
1 | CASE |
说明:
- 语法一通过比较固定的
case_value
与when_value
进行匹配。 - 语法二通过判断条件表达式
search_condition
执行对应的逻辑。
循环
while
while循环是有条件的循环控制语句。满足条件后,再执行循环体中的SQL语句。具体语法为:
1 | -- 先判断条件,如果条件为true,则执行逻辑,否则不执行逻辑 |
repeat
repeat是有条件的循环控制语句,当满足条件的时候退出循环。
语法:
1 | -- 先执行一次循环,如果满足条件,则退出,如果不满足则继续执行循环 |
loop
loop实现简单的循环,如果不在SQL逻辑中增加退出循环的条件,可以用其来实现简单的死循环。l
loop可以配合以下两个语句使用:
- leave:配合循环使用,退出循环。
- iterate:必须用在循环中,作用是跳过当前循环剩下的语句,直接进入下一次循环。
1 | [begin_label:]loop |
游标
-
游标(CURSOR)
- 用于存储查询结果集的数据类型,在存储过程和函数中可对结果集进行循环处理。
-
游标的使用步骤
-
声明游标
1
DECLARE 游标名称 CURSOR FOR 查询语句;
-
打开游标
1
OPEN 游标名称;
-
获取游标记录
1
FETCH 游标名称 INTO 变量 [,变量];
-
关闭游标
1
CLOSE 游标名称;
-
条件处理程序
条件处理程序(Handler)可以用来定义在流程控制结构执行过程中遇到问题时相应的处理步骤。
具体语法:
1 | declare handler_action handler for condition_value[,condition_value]... statement; |
1 | handler_action |
状态码可以参考mysql的官方文档:
MySQL :: MySQL 8.0 Error Reference :: 2 Server Error Message Reference
存储函数
存储函数(function)是有返回值的存储过程,存储函数的参数只能是IN类型。
具体语法:
1 | create function 存储函数名称() |
characteristic说明:
- DETERMINISTIC:相同的输入参数总是产生相同的结果
- NO SQL:不包含SQL语句
- READS SQL DATA:包含读取数据的语句,但不包含写入数据的语句
存储函数并不常用,因为它能完成的事情,存储过程都能完成,但是存储函数还要求必须有返回值,并不普适。
触发器
介绍
- 触发器(trigger)是与表有关的数据序列,指在 insert/update/delete 之前或之后,触发并执行触发器中定义的SQL语句集合。触发器的这种特性可以协助应用在数据库端确保数据的完整性,日志记录,数据校验等操作。
- 使用别名 OLD 和 NEW 来引用触发器中发生变化的记录内容,这与其他的数据库是相似的。现在触发器还只支持行级触发,不支持语句级触发。
触发器类型 | NEW/OLD |
---|---|
INSERT 型触发器 | NEW 表示将要或者已经新增的数据 |
UPDATE 型触发器 | OLD 表示修改之前的数据,NEW 表示将要或已经修改后的数据 |
DELETE 型触发器 | OLD 表示将要或者已经删除的数据 |
创建
1 | create trigger trigger_name |
查看
1 | show triggers; |
删除
1 | drop trigger [schema_name.]trigger_name;-- 如果没有指定schema_name,默认为当前数据库 |
锁
概述
介绍
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中,除传统的计算资源(CPU、RAM、I/O)的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说,锁对数据库而言显得尤为重要,也更加复杂。
分类
MySQL中的锁,按照锁的力度分,分为以下三类:
- 全局锁:锁定数据库中的所有表
- 表级锁:每次操作锁住整张表
- 行级锁:每次操作锁住对应的行数据
全局锁
介绍
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将被阻塞。
其典型的使用场景是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性。
语法
1 | -- 加全局锁 |
一般的备份操作:
1 | mysqldump -uroot -p123456 itcast>itcast.sql |
数据库中加全局锁,是一个比较重的操作,存在以下问题:
-
如果在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆。
-
如果在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志(binlog),会导致主从延迟。
在InnoDB引擎中,我们可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份。
1 | mysqldump --single-transaction -uroot -p123456 itcast>itcast.sql |
表级锁
介绍
表级锁,每次操作锁住整张表。锁定粒度大,发生锁冲突的概率最高,并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。
对于表级锁,主要分为以下三类:
- 表锁
- 元数据锁(meta data lock,MDL)
- 意向锁
表锁
对于表锁,又可以分为两类:
- 表共享读锁(read lock)
- 表独占写锁(write lock)
语法
- 加锁:lock tables 表名… read/write
- 释放锁:unlock tables/客户端断开连接
读锁示意图:
加读锁后两个客户端都只能进行查询操作
写锁示意图:
加写锁后只有加锁客户端既可以读又可以写,其他客户端既不能读也不能写
元数据锁
MDL加锁过程是系统自动控制,无需显式使用,在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作。为了避免DML与DDL冲突,保证读写的正确性。
在MySQL5.5中引入了MDL,当对一张表进行增删改查的时候,加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 … | EXCLUSIVE | 与其他的MDL都互斥 |
查看元数据锁
1 | select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks; |
意向锁
意向锁主要解决的问题是在InnoDB引擎中加的行锁和表锁加锁冲突的问题
- 意向共享锁(IS):由语句 select … lock in share mode添加。
- 意向排他锁(IX):由insert、update、delete、select … for update 添加。
兼容性
- 意向共享锁(IS):与表锁共享锁(read)兼容,与表锁排它锁(write)互斥。
- 意向排他锁(IX):与表锁共享锁(read)及排它锁(write)都互斥。意向锁之间不会互斥。
查看意向锁及行锁的加锁情况:
1 | select object_scema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_locks; |
行级锁
行级锁,每次操作锁住对应的行数据。锁定粒度最小,发生锁冲突的概率最低,并发度最高。应用在InnoDB存储引擎中。
InnoDB的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁。对于行级锁,主要分为以下三类:
- 行锁(Record Lock):锁定单个行记录的锁,防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。
- 间隙锁(Gap Lock):锁定索引记录间隙(不含该记录),确保索引记录间隙不变,防止其他事务在这个间隙进行insert,产生幻读。在RR隔离级别下都支持。
- 临键锁(Next-Key Lock):行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap。在RR隔离级别下支持。
行锁
InnoDB实现了以下两种类型的行锁:
- 共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排它锁。
- 排他锁(X):允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。
当前锁类型|请求锁类型 | S (共享锁) | X (排他锁) |
---|---|---|
S (共享锁) | 兼容 | 冲突 |
X (排他锁) | 冲突 | 冲突 |
执行SQL语句时加的锁类型:
SQL | 行锁类型 | 说明 |
---|---|---|
INSERT … | 排他锁 | 自动加锁 |
UPDATE … | 排他锁 | 自动加锁 |
DELETE … | 排他锁 | 自动加锁 |
SELECT(正常) | 不加任何锁 | |
SELECT … LOCK IN SHARE MODE | 共享锁 | 需要手动在SELECT之后加LOCK IN SHARE MODE |
SELECT … FOR UPDATE | 排他锁 | 需要手动在SELECT之后加FOR UPDATE |
间隙锁/临键锁
默认情况下,InnoDB在 REPEATABLE READ事务隔离级别运行,InnoDB使用 next-key 锁进行搜索和索引扫描,以防止幻读。
- 索引上的等值查询(唯一索引),给不存在的记录加锁时, 优化为间隙锁。
- 索引上的等值查询(普通索引),向右遍历时最后一个值不满足查询需求时,next-key lock 退化为间隙锁。
- 索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。
注意:间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存,一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用间隙锁。