10月底实习准备-Mysql(按面试频率准备)
一.索引
索引是帮助 MySQL 高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查询算法,这种数据结构就是索引。
索引结构(常见)
索引结构 | 描述 |
---|---|
B+Tree | 最常见的索引类型,大部分引擎都支持B+树索引 |
Hash | 底层数据结构是用哈希表实现,只有精确匹配索引列的查询才有效,不支持范围查询 |
几种常考的树
1. 平衡二叉树 (AVL Tree)
-
核心思想:一种严格的平衡二叉搜索树。它要求任何节点的左右子树高度差(平衡因子)的绝对值不超过 1。
-
如何维持平衡:通过四种旋转操作(左旋、右旋、左右旋、右左旋)在插入和删除后重新平衡树。
-
优点:
-
因为平衡严格,所以查询性能非常稳定。查找时间复杂度为
O(log n)
。 -
适用于查询密集型应用。
-
-
缺点:
-
为了维持严格的平衡,插入和删除操作可能需要频繁的旋转,导致性能开销较大。
-
-
为什么不适合做数据库索引?
-
虽然查询快,但“高” 且 “瘦”。对于存储大量数据的数据库来说,
log₂(n)
的树高依然意味着需要很多次的磁盘I/O操作(例如,100万条数据,树高约为20)。而磁盘I/O是数据库操作中最耗时的部分,减少树高就是减少I/O次数,是索引设计的核心目标。
-
2. 红黑树 (Red-Black Tree)
-
核心思想:一种近似平衡的二叉搜索树。它通过一些特定的着色规则来确保从根到叶子的最长可能路径不超过最短可能路径的两倍。
-
规则(简化版):
-
节点是红色或黑色。
-
根节点是黑色。
-
所有叶子节点(NIL)是黑色。
-
红色节点的两个子节点必须是黑色。(即不能有连续的红色节点)
-
从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。
-
-
优点:
-
相比于AVL树,插入和删除操作所需的旋转次数更少,效率更高。是一种折中方案,查询性能尚可,写性能更优。
-
-
缺点:
-
查询效率理论上略低于AVL树,但仍然是
O(log n)
。
-
-
应用场景:广泛应用于内存中的数据结构,如
std::map
in C++,TreeMap
in Java。但它和AVL树一样,因为树高问题,不适合直接作为磁盘数据库索引。
3. B树 (B-Tree)
-
核心思想:一种多路平衡搜索树,专门为磁盘等外部存储设备设计。它不再是二叉树,而是一个节点可以有多个键和多个子节点。
-
重要特性:
-
阶数 (Order)
m
:定义一个节点最多可以有m
个子节点。 -
每个非根、非叶子节点至少包含
ceil(m/2)-1
个键和ceil(m/2)
个子节点(保证了空间的利用率)。 -
所有叶子节点位于同一层,保证了绝对的平衡。
-
-
优点:
-
矮胖:由于是多路分支,树高被大幅降低。同样是100万条数据,一个512阶的B树,树高可能只有3-4层。这极大地减少了磁盘I/O次数,性能提升数个数量级。
-
所有节点都存储数据(键和对应的数据指针/值)。
-
-
缺点:
-
由于节点存储数据,如果数据较大,单个节点能存储的键数量会减少,从而导致树高增加。
-
进行范围查询时,效率不如B+树,需要在内部节点和叶子节点之间来回穿梭。
-
4. B+树 (B+ Tree)
-
核心思想:B树的变种,是现代关系型数据库索引的事实标准。它与B树的核心区别在于:
-
数据只存储在叶子节点:内部节点只存储键,作为导航的索引。
-
叶子节点通过指针串联:所有叶子节点构成一个有序链表。
-
-
优点(正是这些优点使其完美契合数据库需求):
-
更低的树高:内部节点不存储数据,因此一个节点可以容纳更多的键,阶数变得更大,树高变得更矮,I/O次数更少。
-
更稳定的查询性能:任何查找都必须到达叶子节点,时间复杂度稳定为
O(log n)
。 -
极强的范围查询能力:这是B+树相对于B树的杀手级优势。一旦在叶子节点上找到了范围的起点,只需要沿着链表的指针顺序扫描即可,非常高效。而B树则需要不断地进行中序遍历。
-
全盘扫描更快:如果想遍历所有数据,只需要线性地遍历叶子节点链表即可,不需要像B树那样进行树遍历。
-
B-Tree
二叉树的缺点可以用红黑树来解决:
红黑树也存在大数据量情况下,层级较深,检索速度慢的问题。
为了解决上述问题,可以使用 B-Tree 结构。
B-Tree (多路平衡查找树) 以一棵最大度数(max-degree,指一个节点的子节点个数)为5(5阶)的 b-tree 为例(每个节点最多存储4个key,5个指针)
B-Tree 的数据插入过程动画参照:https://www.bilibili.com/video/BV1Kr4y1i7ru?p=68
演示地址:https://www.cs.usfca.edu/~galles/visualization/BTree.html
B+Tree
结构图:
演示地址:https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html
与 B-Tree 的区别:
- 所有的数据都会出现在叶子节点
- 叶子节点形成一个单向链表
MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上,增加一个指向相邻叶子节点的链表指针,就形成了带有顺序指针的 B+Tree,提高区间访问的性能。
Hash
哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中。
如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了hash冲突(也称为hash碰撞),可以通过链表来解决。
特点:
- Hash索引只能用于对等比较(=、in),不支持范围查询(betwwn、>、<、…)
- 无法利用索引完成排序操作
- 查询效率高,通常只需要一次检索就可以了,效率通常要高于 B+Tree 索引
面试题
- 为什么 InnoDB 存储引擎选择使用 B+Tree 索引结构?
- 相对于二叉树,层级更少,搜索效率高
- 对于 B-Tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储的键值减少,指针也跟着减少,要同样保存大量数据,只能增加树的高度,导致性能降低
- 相对于 Hash 索引,B+Tree 支持范围匹配及排序操作
索引分类
分类 | 含义 | 特点 | 关键字 |
---|---|---|---|
主键索引 | 针对于表中主键创建的索引 | 默认自动创建,只能有一个 | PRIMARY |
唯一索引 | 避免同一个表中某数据列中的值重复 | 可以有多个 | UNIQUE |
常规索引 | 快速定位特定数据 | 可以有多个 | |
全文索引 | 全文索引查找的是文本中的关键词,而不是比较索引中的值 | 可以有多个 | FULLTEXT |
在 InnoDB 存储引擎中,根据索引的存储形式,又可以分为以下两种:
分类 | 含义 | 特点 |
---|---|---|
聚集索引(Clustered Index) | 将数据存储与索引放一块,索引结构的叶子节点保存了行数据 | 必须有,而且只有一个 |
二级索引(Secondary Index) | 将数据与索引分开存储,索引结构的叶子节点关联的是对应的主键 | 可以存在多个 |
演示图:
聚集索引选取规则:
- 如果存在主键,主键索引就是聚集索引
- 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引
- 如果表没有主键或没有合适的唯一索引,则 InnoDB 会自动生成一个 rowid 作为隐藏的聚集索引
思考题
1. 以下 SQL 语句,哪个执行效率高?为什么?
select * from user where id = 10; select * from user where name = 'Arm'; -- 备注:id为主键,name字段创建的有索引 |
答:第一条语句,因为第二条需要回表查询,相当于两个步骤。
2. InnoDB 主键索引的 B+Tree 高度为多少?
答:假设一行数据大小为1k,一页中可以存储16行这样的数据。InnoDB 的指针占用6个字节的空间,主键假设为bigint,占用字节数为8.
可得公式:n * 8 + (n + 1) * 6 = 16 * 1024
,其中 8 表示 bigint 占用的字节数,n 表示当前节点存储的key的数量,(n + 1) 表示指针数量(比key多一个)。算出n约为1170。
如果树的高度为2,那么他能存储的数据量大概为:1171 * 16 = 18736
;
如果树的高度为3,那么他能存储的数据量大概为:1171 * 1171 * 16 = 21939856
。
另外,如果有成千上万的数据,那么就要考虑分表,涉及运维篇知识。
语法
创建索引:
CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name, ...);
如果不加 CREATE 后面不加索引类型参数,则创建的是常规索引
查看索引:
SHOW INDEX FROM table_name;
删除索引:
DROP INDEX index_name ON table_name;
使用规则
最左前缀法则
如果索引关联了多列(联合索引),要遵守最左前缀法则,最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列。
如果跳跃某一列,索引将部分失效(后面的字段索引失效)。
联合索引中,出现范围查询(<, >),范围查询右侧的列索引失效。可以用>=或者<=来规避索引失效问题。
索引失效情况
- 在索引列上进行运算操作,索引将失效。如:
explain select * from tb_user where substring(phone, 10, 2) = '15';
- 字符串类型字段使用时,不加引号,索引将失效。如:
explain select * from tb_user where phone = 17799990015;
,此处phone的值没有加引号 - 模糊查询中,如果仅仅是尾部模糊匹配,索引不会是失效;如果是头部模糊匹配,索引失效。如:
explain select * from tb_user where profession like '%工程';
,前后都有 % 也会失效。 - 用 or 分割开的条件,如果 or 其中一个条件的列没有索引,那么涉及的索引都不会被用到。
- 如果 MySQL 评估使用索引比全表更慢,则不使用索引。
二.事务
事务是一组操作的集合,事务会把所有操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。
默认MySQL的事务是自动提交的,也就是说,当执行一条DML语句,MySQL会立即隐式的提交事务
对于我们业务操作来说,如果业务操作正常完成,事务需要提交执行commit指令,事务需要提交执行commit指令,此时数据库的数据就会变更过来,如果在执行事务的过程中出现了异常,我们会执行roll back回滚事务,此时数据库当中的数据就可以包装其正确性和完整性
四大特性ACID
- 原子性(Atomicity):事务是不可分割的最小操作单元,要么全部成功,要么全部失败
- 一致性(Consistency):事务完成时,必须使所有数据都保持一致状态
- 隔离性(Isolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行
- 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变就是永久的
并发事务
问题 | 描述 |
---|---|
脏读 | 一个事务读到另一个事务还没提交的数据 |
不可重复读 | 一个事务先后读取同一条记录,但两次读取的数据不同 |
幻读 | 一个事务按照条件查询数据时,没有对应的数据行,但是再插入数据时,又发现这行数据已经存在 |
并发事务隔离级别:
读未提交 读已提交 可重复读 串行化
性能越来越差
数据安全性越来越高
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
Read uncommitted | √ | √ | √ |
Read committed | × | √ | √ |
Repeatable Read(默认) | × | × | √ |
Serializable | × | × | × |
特性原理分类图:
redo log
重做日志,记录的是事务提交时数据页的物理修改,是用来实现事务的持久性。
该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file),前者是在内存中,后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中,用于在刷新脏页到磁盘,发生错误时,进行数据恢复使用。
Buffer Pool在产生脏页数据的时候,会先将数据存储到 redo log buffer 再存储到 redo log 中进行磁盘持久化存储,在内存出现异常(比如突然断电)时,通过redo log中持久化的数据进行回滚。过程如下图:
redo log 要写到磁盘,数据也要写磁盘,为什么要多此一举?
写入 redo log 的方式使用了追加操作,所以磁盘操作是顺序写,而写入数据需要先找到写入位置,然后才写到磁盘,所以磁盘操作是随机写。
undo log
用来解决事务原子性
回滚日志,用于记录数据被修改前的信息,作用包含两个:提供回滚 和 MVCC(多版本并发控制)。
undo log 和 redo log 记录物理日志不一样,它是逻辑日志。可以认为当 delete 一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当 update 一条记录时,它记录一条对应相反的 update 记录。当执行 rollback 时,就可以从 undo log 中的逻辑记录读取到相应的内容并进行回滚。
Undo log 销毁:undo log 在事务执行时产生,事务提交时,并不会立即删除undol0g,因为这些日志可能还用于 MVCC。
Undo log 存储:undo log 采用段的方式进行管理和记录,存放在前面介绍的 rollback segment 回滚段中,内部包含1024个 undo log segment.
MVCC
当前读:
读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select…lock in share mode(共享锁),select… for update、update、insert、delete(排他锁)都是一种当前读。
快照读:
简单的select(不加锁)就是快照读,快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
- Read committed:每次select,都生成一个快照读。
- Repeatable Read:开启事务后第一个select语句才是快照读的地方。
- Serializable:快照读会退化为当前读。
MVCC:
全称 Multi-Version Concurrency Control,多版本并发控制。指维护一个数据的多个版本,使得读写操作没有冲突,快照读为MVSOL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段、undo log日志、read View。
三个隐藏字段
undo log
回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候,产生的undoloq日志只在回滚时需要,在事务提交后,可被立即删除。
而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。
那么何时删除?
- 事务提交后:
- 对于
INSERT
操作,事务提交后,undo log可以被立即删除,因为不再需要用于回滚。 - 对于
UPDATE
和DELETE
操作,undo log不会立即被删除,因为它们可能在后续的快照读取中被使用。
- 对于
- 快照读取结束:
- 当所有依赖于该undo log的快照读取操作结束后,undo log才会被删除。这意味着如果有一个事务正在进行快照读取,并且依赖于某个undo log,那么这个undo log会一直保留直到该事务结束。
-
readview
ReadView(读视图)是 快照读 SOL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id。
ReadView中包含了四个核心字段:
字段 | 含义 |
---|---|
m_ids | 当前活跃的事务ID集合 |
min_trx_id | 最小活跃事务ID |
max_trx_id | 预分配事务ID,当前最大事务ID+1(因为事务ID是自增的) |
creator_trx_id | ReadView创建者的事务ID |
依次比较 undo log 日志中版本数据链,找到可以进行访问的版本数据。
三.SQL语法
通用语法及分类
- DDL: 数据定义语言,用来定义数据库对象(数据库、表、字段)
- DML: 数据操作语言,用来对数据库表中的数据进行增删改
- DQL: 数据查询语言,用来查询数据库中表的记录
- DCL: 数据控制语言,用来创建数据库用户、控制数据库的控制权限
DDL(数据定义语言)
数据定义语言
数据库操作
查询所有数据库:
SHOW DATABASES;
查询当前数据库:
SELECT DATABASE();
创建数据库:
CREATE DATABASE [ IF NOT EXISTS ] 数据库名 [ DEFAULT CHARSET 字符集] [COLLATE 排序规则 ];
删除数据库:
DROP DATABASE [ IF EXISTS ] 数据库名;
使用数据库:
USE 数据库名;
注意事项
- UTF8字符集长度为3字节,有些符号占4字节,所以推荐用utf8mb4字符集
表操作
查询当前数据库所有表:
SHOW TABLES;
查询表结构:
DESC 表名;
查询指定表的建表语句:
SHOW CREATE TABLE 表名;
创建表:
CREATE TABLE 表名(字段1 字段1类型 [COMMENT 字段1注释],字段2 字段2类型 [COMMENT 字段2注释],字段3 字段3类型 [COMMENT 字段3注释],...字段n 字段n类型 [COMMENT 字段n注释] )[ COMMENT 表注释 ]; |
最后一个字段后面没有逗号
添加字段:
ALTER TABLE 表名 ADD 字段名 类型(长度) [COMMENT 注释] [约束];
例:ALTER TABLE emp ADD nickname varchar(20) COMMENT '昵称';
修改数据类型:
ALTER TABLE 表名 MODIFY 字段名 新数据类型(长度);
修改字段名和字段类型:
ALTER TABLE 表名 CHANGE 旧字段名 新字段名 类型(长度) [COMMENT 注释] [约束];
例:将emp表的nickname字段修改为username,类型为varchar(30)
ALTER TABLE emp CHANGE nickname username varchar(30) COMMENT '昵称';
删除字段:
ALTER TABLE 表名 DROP 字段名;
修改表名:
ALTER TABLE 表名 RENAME TO 新表名
删除表:
DROP TABLE [IF EXISTS] 表名;
删除表,并重新创建该表:
TRUNCATE TABLE 表名;
DML(数据操作语言)
添加数据
指定字段:
INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...);
全部字段:
INSERT INTO 表名 VALUES (值1, 值2, ...);
批量添加数据:
INSERT INTO 表名 (字段名1, 字段名2, ...) VALUES (值1, 值2, ...), (值1, 值2, ...), (值1, 值2, ...);
INSERT INTO 表名 VALUES (值1, 值2, ...), (值1, 值2, ...), (值1, 值2, ...);
注意事项
- 字符串和日期类型数据应该包含在引号中
- 插入的数据大小应该在字段的规定范围内
更新和删除数据
修改数据:
UPDATE 表名 SET 字段名1 = 值1, 字段名2 = 值2, ... [ WHERE 条件 ];
例:
UPDATE emp SET name = 'Jack' WHERE id = 1;
删除数据:
DELETE FROM 表名 [ WHERE 条件 ];
DQL(数据查询语言)
语法:
SELECT字段列表 FROM表名字段 WHERE条件列表 GROUP BY分组字段列表 HAVING分组后的条件列表 ORDER BY排序字段列表 LIMIT分页参数 |
基础查询
查询多个字段:
SELECT 字段1, 字段2, 字段3, ... FROM 表名;
SELECT * FROM 表名;
设置别名:
SELECT 字段1 [ AS 别名1 ], 字段2 [ AS 别名2 ], 字段3 [ AS 别名3 ], ... FROM 表名;
SELECT 字段1 [ 别名1 ], 字段2 [ 别名2 ], 字段3 [ 别名3 ], ... FROM 表名;
去除重复记录:
SELECT DISTINCT 字段列表 FROM 表名;
转义:
SELECT * FROM 表名 WHERE name LIKE '/_张三' ESCAPE '/'
/ 之后的_不作为通配符
条件查询
语法:
SELECT 字段列表 FROM 表名 WHERE 条件列表;
条件:
比较运算符 | 功能 |
---|---|
> | 大于 |
>= | 大于等于 |
< | 小于 |
<= | 小于等于 |
= | 等于 |
<> 或 != | 不等于 |
BETWEEN … AND … | 在某个范围内(含最小、最大值) |
IN(…) | 在in之后的列表中的值,多选一 |
LIKE 占位符 | 模糊匹配(_匹配单个字符,%匹配任意个字符) |
IS NULL | 是NULL |
逻辑运算符 | 功能 |
---|---|
AND 或 && | 并且(多个条件同时成立) |
OR 或 || | 或者(多个条件任意一个成立) |
NOT 或 ! | 非,不是 |
例子:
-- 年龄等于30 select * from employee where age = 30; -- 年龄小于30 select * from employee where age < 30; -- 小于等于 select * from employee where age <= 30; -- 没有身份证 select * from employee where idcard is null or idcard = ''; -- 有身份证 select * from employee where idcard; select * from employee where idcard is not null; -- 不等于 select * from employee where age != 30; -- 年龄在20到30之间 select * from employee where age between 20 and 30; select * from employee where age >= 20 and age <= 30; -- 下面语句不报错,但查不到任何信息 select * from employee where age between 30 and 20; -- 性别为女且年龄小于30 select * from employee where age < 30 and gender = '女'; -- 年龄等于25或30或35 select * from employee where age = 25 or age = 30 or age = 35; select * from employee where age in (25, 30, 35); -- 姓名为两个字 select * from employee where name like '__'; -- 身份证最后为X select * from employee where idcard like '%X'; |
聚合查询(聚合函数)
常见聚合函数:
函数 | 功能 |
---|---|
count | 统计数量 |
max | 最大值 |
min | 最小值 |
avg | 平均值 |
sum | 求和 |
语法:
SELECT 聚合函数(字段列表) FROM 表名;
例:
SELECT count(id) from employee where workaddress = "广东省";
分组查询
语法:
SELECT 字段列表 FROM 表名 [ WHERE 条件 ] GROUP BY 分组字段名 [ HAVING 分组后的过滤条件 ];
where 和 having 的区别:
- 执行时机不同:where是分组之前进行过滤,不满足where条件不参与分组;having是分组后对结果进行过滤。
- 判断条件不同:where不能对聚合函数进行判断,而having可以。
例子:
-- 根据性别分组,统计男性和女性数量(只显示分组数量,不显示哪个是男哪个是女) select count(*) from employee group by gender; -- 根据性别分组,统计男性和女性数量 select gender, count(*) from employee group by gender; -- 根据性别分组,统计男性和女性的平均年龄 select gender, avg(age) from employee group by gender; -- 年龄小于45,并根据工作地址分组 select workaddress, count(*) from employee where age < 45 group by workaddress; -- 年龄小于45,并根据工作地址分组,获取员工数量大于等于3的工作地址 select workaddress, count(*) address_count from employee where age < 45 group by workaddress having address_count >= 3; |
注意事项
- 执行顺序:where > 聚合函数 > having
- 分组之后,查询的字段一般为聚合函数和分组字段,查询其他字段无任何意义
排序查询
语法:
SELECT 字段列表 FROM 表名 ORDER BY 字段1 排序方式1, 字段2 排序方式2;
排序方式:
- ASC: 升序(默认)
- DESC: 降序
例子:
-- 根据年龄升序排序 SELECT * FROM employee ORDER BY age ASC; SELECT * FROM employee ORDER BY age; -- 两字段排序,根据年龄升序排序,入职时间降序排序 SELECT * FROM employee ORDER BY age ASC, entrydate DESC; |
注意事项
如果是多字段排序,当第一个字段值相同时,才会根据第二个字段进行排序
分页查询
语法:
SELECT 字段列表 FROM 表名 LIMIT 起始索引, 查询记录数;
例子:
-- 查询第一页数据,展示10条 SELECT * FROM employee LIMIT 0, 10; -- 查询第二页 SELECT * FROM employee LIMIT 10, 10; |
注意事项
- 起始索引从0开始,起始索引 = (查询页码 - 1) * 每页显示记录数
- 分页查询是数据库的方言,不同数据库有不同实现,MySQL是LIMIT
- 如果查询的是第一页数据,起始索引可以省略,直接简写 LIMIT 10
DQL执行顺序
FROM -> WHERE -> GROUP BY -> SELECT -> ORDER BY -> LIMIT
DCL
管理用户
查询用户:
USE mysql; SELECT * FROM user; |
创建用户:
CREATE USER '用户名'@'主机名' IDENTIFIED BY '密码';
修改用户密码:
ALTER USER '用户名'@'主机名' IDENTIFIED WITH mysql_native_password BY '新密码';
删除用户:
DROP USER '用户名'@'主机名';
例子:
-- 创建用户test,只能在当前主机localhost访问 create user 'test'@'localhost' identified by '123456'; -- 创建用户test,能在任意主机访问 create user 'test'@'%' identified by '123456'; create user 'test' identified by '123456'; -- 修改密码 alter user 'test'@'localhost' identified with mysql_native_password by '1234'; -- 删除用户 drop user 'test'@'localhost'; |
注意事项
- 主机名可以使用 % 通配
权限控制
常用权限:
权限 | 说明 |
---|---|
ALL, ALL PRIVILEGES | 所有权限 |
SELECT | 查询数据 |
INSERT | 插入数据 |
UPDATE | 修改数据 |
DELETE | 删除数据 |
ALTER | 修改表 |
DROP | 删除数据库/表/视图 |
CREATE | 创建数据库/表 |
更多权限请看权限一览表
查询权限:
SHOW GRANTS FOR '用户名'@'主机名';
授予权限:
GRANT 权限列表 ON 数据库名.表名 TO '用户名'@'主机名';
撤销权限:
REVOKE 权限列表 ON 数据库名.表名 FROM '用户名'@'主机名';
注意事项
- 多个权限用逗号分隔
- 授权时,数据库名和表名可以用 * 进行通配,代表所有
函数
- 字符串函数
- 数值函数
- 日期函数
- 流程函数
字符串函数
常用函数:
函数 | 功能 |
---|---|
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) | 替换字符串 |
使用示例:
-- 拼接 SELECT CONCAT('Hello', 'World'); -- 小写 SELECT LOWER('Hello'); -- 大写 SELECT UPPER('Hello'); -- 左填充 SELECT LPAD('01', 5, '-'); -- 右填充 SELECT RPAD('01', 5, '-'); -- 去除空格 SELECT TRIM(' Hello World '); -- 切片(起始索引为1) SELECT SUBSTRING('Hello World', 1, 5); |
数值函数
常见函数:
函数 | 功能 |
---|---|
CEIL(x) | 向上取整 |
FLOOR(x) | 向下取整 |
MOD(x, y) | 返回x/y的模 |
RAND() | 返回0~1内的随机数 |
ROUND(x, y) | 求参数x的四舍五入值,保留y位小数 |
日期函数
常用函数:
函数 | 功能 |
---|---|
CURDATE() | 返回当前日期 |
CURTIME() | 返回当前时间 |
NOW() | 返回当前日期和时间 |
YEAR(date) | 获取指定date的年份 |
MONTH(date) | 获取指定date的月份 |
DAY(date) | 获取指定date的日期 |
DATE_ADD(date, INTERVAL expr type) | 返回一个日期/时间值加上一个时间间隔expr后的时间值 |
DATEDIFF(date1, date2) | 返回起始时间date1和结束时间date2之间的天数 |
例子:
-- DATE_ADD SELECT DATE_ADD(NOW(), INTERVAL 70 YEAR); |
流程函数
常用函数:
函数 | 功能 |
---|---|
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默认值 |
例子:
selectname,(case when age > 30 then '中年' else '青年' end) from employee; selectname,(case workaddress when '北京市' then '一线城市' when '上海市' then '一线城市' else '二线城市' end) as '工作地址' from employee; |
约束
分类:
约束 | 描述 | 关键字 |
---|---|---|
非空约束 | 限制该字段的数据不能为null | NOT NULL |
唯一约束 | 保证该字段的所有数据都是唯一、不重复的 | UNIQUE |
主键约束 | 主键是一行数据的唯一标识,要求非空且唯一 | PRIMARY KEY |
默认约束 | 保存数据时,如果未指定该字段的值,则采用默认值 | DEFAULT |
检查约束(8.0.1版本后) | 保证字段值满足某一个条件 | CHECK |
外键约束 | 用来让两张图的数据之间建立连接,保证数据的一致性和完整性 | FOREIGN KEY |
约束是作用于表中字段上的,可以再创建表/修改表的时候添加约束。
常用约束
约束条件 | 关键字 |
---|---|
主键 | PRIMARY KEY |
自动增长 | AUTO_INCREMENT |
不为空 | NOT NULL |
唯一 | UNIQUE |
逻辑条件 | CHECK |
默认值 | DEFAULT |
例子:
create table user(id int primary key auto_increment,name varchar(10) not null unique,age int check(age > 0 and age < 120),status char(1) default '1',gender char(1) ); |
外键约束
添加外键:
CREATE TABLE 表名(字段名 字段类型,...[CONSTRAINT] [外键名称] FOREIGN KEY(外键字段名) REFERENCES 主表(主表列名) ); ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名) REFERENCES 主表(主表列名);-- 例子 alter table emp add constraint fk_emp_dept_id foreign key(dept_id) references dept(id); |
删除外键:
ALTER TABLE 表名 DROP FOREIGN KEY 外键名;
删除/更新行为
行为 | 说明 |
---|---|
NO ACTION | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则不允许删除/更新(与RESTRICT一致) |
RESTRICT | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则不允许删除/更新(与NO ACTION一致) |
CASCADE | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则也删除/更新外键在子表中的记录 |
SET NULL | 当在父表中删除/更新对应记录时,首先检查该记录是否有对应外键,如果有则设置子表中该外键值为null(要求该外键允许为null) |
SET DEFAULT | 父表有变更时,子表将外键设为一个默认值(Innodb不支持) |
更改删除/更新行为:
ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段) REFERENCES 主表名(主表字段名) ON UPDATE 行为 ON DELETE 行为;
多表查询
多表关系
- 一对多(多对一)
- 多对多
- 一对一
一对多
案例:部门与员工
关系:一个部门对应多个员工,一个员工对应一个部门
实现:在多的一方建立外键,指向一的一方的主键
多对多
案例:学生与课程
关系:一个学生可以选多门课程,一门课程也可以供多个学生选修
实现:建立第三张中间表,中间表至少包含两个外键,分别关联两方主键
一对一
案例:用户与用户详情
关系:一对一关系,多用于单表拆分,将一张表的基础字段放在一张表中,其他详情字段放在另一张表中,以提升操作效率
实现:在任意一方加入外键,关联另外一方的主键,并且设置外键为唯一的(UNIQUE)
查询
合并查询(笛卡尔积,会展示所有组合结果):
select * from employee, dept;
笛卡尔积:两个集合A集合和B集合的所有组合情况(在多表查询时,需要消除无效的笛卡尔积)
消除无效笛卡尔积:
select * from employee, dept where employee.dept = dept.id;
内连接查询
内连接查询的是两张表交集的部分
隐式内连接:
SELECT 字段列表 FROM 表1, 表2 WHERE 条件 ...;
显式内连接:
SELECT 字段列表 FROM 表1 [ INNER ] JOIN 表2 ON 连接条件 ...;
显式性能比隐式高
例子:
-- 查询员工姓名,及关联的部门的名称 -- 隐式 select e.name, d.name from employee as e, dept as d where e.dept = d.id; -- 显式 select e.name, d.name from employee as e inner join dept as d on e.dept = d.id; |
外连接查询
左外连接:
查询左表所有数据,以及两张表交集部分数据
SELECT 字段列表 FROM 表1 LEFT [ OUTER ] JOIN 表2 ON 条件 ...;
相当于查询表1的所有数据,包含表1和表2交集部分数据
右外连接:
查询右表所有数据,以及两张表交集部分数据
SELECT 字段列表 FROM 表1 RIGHT [ OUTER ] JOIN 表2 ON 条件 ...;
例子:
-- 左 select e.*, d.name from employee as e left outer join dept as d on e.dept = d.id; select d.name, e.* from dept d left outer join emp e on e.dept = d.id; -- 这条语句与下面的语句效果一样 -- 右 select d.name, e.* from employee as e right outer join dept as d on e.dept = d.id; |
左连接可以查询到没有dept的employee,右连接可以查询到没有employee的dept
自连接查询
当前表与自身的连接查询,自连接必须使用表别名
语法:
SELECT 字段列表 FROM 表A 别名A JOIN 表A 别名B ON 条件 ...;
自连接查询,可以是内连接查询,也可以是外连接查询
例子:
-- 查询员工及其所属领导的名字 select a.name, b.name from employee a, employee b where a.manager = b.id; -- 没有领导的也查询出来 select a.name, b.name from employee a left join employee b on a.manager = b.id; |
联合查询 union, union all
把多次查询的结果合并,形成一个新的查询集
语法:
SELECT 字段列表 FROM 表A ... UNION [ALL] SELECT 字段列表 FROM 表B ... |
注意事项
- UNION ALL 会有重复结果,UNION 不会
- 联合查询比使用or效率高,不会使索引失效
子查询
SQL语句中嵌套SELECT语句,称谓嵌套查询,又称子查询。
SELECT * FROM t1 WHERE column1 = ( SELECT column1 FROM t2);
子查询外部的语句可以是 INSERT / UPDATE / DELETE / SELECT 的任何一个
根据子查询结果可以分为:
- 标量子查询(子查询结果为单个值)
- 列子查询(子查询结果为一列)
- 行子查询(子查询结果为一行)
- 表子查询(子查询结果为多行多列)
根据子查询位置可分为:
- WHERE 之后
- FROM 之后
- SELECT 之后
标量子查询
子查询返回的结果是单个值(数字、字符串、日期等)。
常用操作符:- < > > >= < <=
例子:
-- 查询销售部所有员工 select id from dept where name = '销售部'; -- 根据销售部部门ID,查询员工信息 select * from employee where dept = 4; -- 合并(子查询) select * from employee where dept = (select id from dept where name = '销售部');-- 查询xxx入职之后的员工信息 select * from employee where entrydate > (select entrydate from employee where name = 'xxx'); |
列子查询
返回的结果是一列(可以是多行)。
常用操作符:
操作符 | 描述 |
---|---|
IN | 在指定的集合范围内,多选一 |
NOT IN | 不在指定的集合范围内 |
ANY | 子查询返回列表中,有任意一个满足即可 |
SOME | 与ANY等同,使用SOME的地方都可以使用ANY |
ALL | 子查询返回列表的所有值都必须满足 |
例子:
-- 查询销售部和市场部的所有员工信息 select * from employee where dept in (select id from dept where name = '销售部' or name = '市场部'); -- 查询比财务部所有人工资都高的员工信息 select * from employee where salary > all(select salary from employee where dept = (select id from dept where name = '财务部')); -- 查询比研发部任意一人工资高的员工信息 select * from employee where salary > any (select salary from employee where dept = (select id from dept where name = '研发部')); |
行子查询
返回的结果是一行(可以是多列)。
常用操作符:=, <, >, IN, NOT IN
例子:
-- 查询与xxx的薪资及直属领导相同的员工信息 select * from employee where (salary, manager) = (12500, 1); select * from employee where (salary, manager) = (select salary, manager from employee where name = 'xxx'); |
表子查询
返回的结果是多行多列
常用操作符:IN
例子:
-- 查询与xxx1,xxx2的职位和薪资相同的员工 select * from employee where (job, salary) in (select job, salary from employee where name = 'xxx1' or name = 'xxx2'); -- 查询入职日期是2006-01-01之后的员工,及其部门信息 select e.*, d.* from (select * from employee where entrydate > '2006-01-01') as e left join dept as d on e.dept = d.id; |
四.乐观锁
是数据库和数据并发控制领域的一个核心概念。
一、核心思想:先乐观,后验证
为了理解乐观锁,我们先看一个生活中的例子:
场景:多人同时在线编辑同一个云文档(比如腾讯文档或Google Docs)。
-
乐观的假设:系统不会假设你们会编辑同一个段落而直接阻止你编辑。它乐观地允许你们所有人同时打开文档进行修改。
-
提交时的验证:当你按下“保存”时,系统才会进行检查。它会比较你开始编辑时的文档版本和现在服务器上的文档版本。
-
如果版本一致:说明在你编辑期间没有其他人修改过同一区域,你的修改成功保存。
-
如果版本不一致:说明有别人已经修改并保存了(比如别人修改了你正在修改的段落),系统会拒绝你的提交,并通常会提示你“文档已被他人更新,请基于最新版本重新编辑”。
-
这个“比较版本号”的过程,就是乐观锁的核心。
二、与悲观锁的对比:理解两种不同的并发哲学
要深刻理解乐观锁,最好的方法是和它的“对手”——悲观锁进行对比。
特性 | 悲观锁 | 乐观锁 |
---|---|---|
核心思想 | “悲观”假设:认为并发冲突很可能会发生,所以要先下手为强。 | “乐观”假设:认为并发冲突不太会发生,所以先放开操作。 |
工作机制 | 在读取数据时就直接加锁(行锁、表锁),阻止其他事务读写。类似于 “独占”。 | 读取数据时不加锁,在更新数据时才检查此期间数据是否被他人改动。 |
类比 | 图书馆借书:你想借一本热门书,管理员直接把它锁在柜子里,在你归还前谁也借不走。 | 云文档编辑:见上例。 |
实现方式 | 使用数据库的锁机制(如 SELECT ... FOR UPDATE )。 | 使用版本号字段或时间戳字段。 |
适用场景 | 冲突频繁、竞争激烈的场景(如抢购、秒杀中扣减库存)。写操作多,读操作少的场景。 | 冲突较少、读多写少的场景(如新闻详情页的点赞、评论系统)。大部分Web应用都属于此类。 |
优点 | 能保证操作的强一致性,实现简单。 | 性能高,不会产生锁等待,吞吐量高。 |
缺点 | 性能开销大,加锁时间长会严重影响并发能力,容易导致死锁。 | 在冲突真的发生时,操作会失败,需要业务逻辑来处理重试或提示用户。 |
三、乐观锁的技术实现(核心部分)
乐观锁在数据库中没有直接的锁命令,它是一种逻辑上的锁,通常通过以下两种方式实现:
1. 版本号机制(最常用、最推荐)
在数据库表中增加一个 version
字段(整数类型)。
工作流程如下:
-
读取数据:事务A读取某条记录,同时获取当前的版本号(例如
version = 1
)。 -
修改数据:事务A在内存中修改数据。
-
提交更新:事务A执行更新语句时,将版本号作为更新条件。
sql
UPDATE table_name SET column1 = new_value, version = version + 1 WHERE id = #{id} AND version = #{old_version};
-
#{old_version}
就是第一步中读取到的1
。
-
-
验证结果:
-
成功:如果这条记录在事务A读取后没有被其他事务修改,那么数据库中的
version
还是1
。WHERE条件成立,更新成功,同时version
被设置为2
。数据库返回“1行被影响”。 -
失败:如果在这期间事务B已经成功更新了该记录,那么数据库中的
version
已经变成了2
。WHERE条件(version = 1
)不成立,更新失败。数据库返回“0行被影响”。
-
2. 时间戳机制
原理与版本号类似,只是将 version
字段换成了一个 last_updated_timestamp
字段。
更新时的SQL语句变为:
sql
UPDATE table_name SET column1 = new_value, last_updated_timestamp = CURRENT_TIMESTAMP WHERE id = #{id} AND last_updated_timestamp = #{old_timestamp};
为什么版本号比时间戳更常用?
因为时间戳的精度取决于数据库系统,在极高并发下,两个操作可能在同一个时间戳内完成,导致验证不准确。而版本号是整数自增,可以确保绝对唯一性。
四、乐观锁的ABA问题及其解决方案
ABA问题是什么?
这是一个经典问题。假设事务A读取数据时 version=1
。
-
事务B先执行,将数据从A改成B,
version
变成2
。 -
然后事务C又执行,将数据从B改回了A,
version
变成3
。 -
此时事务A开始提交更新,它发现当前数据值还是A(和它读的时候一样),并且
version=3
不等于它读取的1
,所以更新会失败。
但是,如果我们的版本号机制不是整数自增,而是基于数据值本身(比如一个状态字段)来判断,就会出问题:
事务A看到值还是A,就以为数据没被改动过,其实中间已经经历了B和C两次修改。这就是ABA问题。
解决方案:
使用递增的版本号(如整数自增)或时间戳可以完美解决ABA问题。因为即使值变回了A,版本号也一定是递增的(从1到2再到3),事务A提交时用旧的版本号1一定无法更新成功。所以,我们上面推荐的版本号机制本身就天然避免了ABA问题。
五、在应用程序中如何处理乐观锁冲突?
当更新返回“0行受影响”时,意味着乐观锁冲突发生了。应用程序不能直接报错,应该有妥善的处理策略:
-
失败重试:自动重新执行整个“读取-计算-更新”的业务流程。这是最常用的方法。可以设置一个最大重试次数。
-
告知用户:直接向用户返回友好提示,如“数据已发生变化,请刷新页面后重试”。
总结
-
乐观锁是一种无锁的并发控制方案,核心是 “版本号” 和 “更新时验证”。
-
它适用于读多写少、冲突概率低的场景,能极大提升系统性能和吞吐量。
-
它的实现不依赖于数据库的锁,而是在应用逻辑中通过带版本号的UPDATE语句完成。
-
当冲突发生时,需要通过重试机制或提示用户来处理。