高性能MySQL(第4版) 第一章 MySQL架构读书笔记

2023年5月10日 82点热度 0人点赞 0条评论

这本书去年11月出的,今年中文版也出了,并且直接上了微信读书,之后有空就读一读,分享下读书笔记~

原文内容比较充实,建议有时间可以读一下原文.
第一章主要是个概览.

MySQL的逻辑架构

默认情况下,每个客户端连接都会在服务器进程中拥有一个线程,该连接的查询只会在这个单独的线程中执行,该线程驻留在一个内核或者CPU上.
线程池

优化器会向存储引擎询问它的一些功能、某个具体操作的成本,以及表数据的统计信息.

query cache 5.7.20弃用 8.0移除
考虑应用自己在redis中缓存

并发控制

只要有多个查询需要同时修改数据,就会产生并发控制问题

读写锁

处理并发读/写访问的系统通常实现一个由两种锁类型组成的锁系统
这两种锁通常被称为共享锁(shared lock)和排他锁(exclusive lock),也叫读锁(read lock)和写锁(write lock)

锁的粒度

通过降低锁的粒度提高共享资源并发性
只锁定包含需要修改的部分数据

表锁

table lock
最基本开销最小的锁策略(锁本身的开销不是指查询/修改性能)

行级锁

row lock
最大程度支持并发处理最大的锁开销
行级锁是在存储引擎中实现

事务

事务就是一组SQL语句,作为一个工作单元以原子方式进行处理
要么全部执行成功要么全部执行失败

ACID

隔离级别

这里谈的是ANSI SQL中的定义

READ UNCOMMITTED: 未提交读
在事务中可以查看其他事务中还没有提交的修改
脏读(dirty read): 读取未提交的数据
READ COMMITTED: 已提交读
大多数数据库系统的默认级别
但MySQL不是
一个事务可以看到其他事务在它开始之后提交的修改,但在该事务提交之前,其所做的任何修改对其他事务都是不可见的.
允许不可重复读(nonrepeatable read) 同一个事务中两次执行相同语句可能看到不同结果
REPEATABLE READ: 可重复读
解决了不可重复读
无法解决幻读(phantom read) 读取范围数据时如果另一个事务在该范围插入了新的再次读取会产生换行(phantom row)
InnoDB和XtraDB通过MVCC解决
这也是MySQL默认的隔离级别
SERIALIZABLE: 可串行化
该级别通过强制事务按序执行,使不同事务之间不可能产生冲突,从而解决了前面说的幻读问题.
会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题.
使用场景较少除非需要严格确保数据安全并且接收并发性能下降

死锁

两个或多个事务相互持有和请求相同资源上的锁,产生了循环依赖.
当多个事务试图以不同的顺序锁定资源时会导致死锁.

数据库系统实现了各种是说检测和锁超时机制
InnoDB目前处理死锁的方式是将持有最少行级排他锁的事务回滚
锁的行为和顺序和存储引擎相关

console1:
start transaction ;
update user set user_name='cc11' where user_id=1;
update user set user_name='cc22' where user_id=2;
commit ;

console2:
start transaction ;
update user set user_name='cc222' where user_id=2;
update user set user_name='cc111' where user_id=1;
commit ;

单步执行

[40001][1213] Deadlock found when trying to get lock; try restarting transaction

事务日志

事务日志有助于提高事务的效率.存储引擎只需要更改内存中的数据副本,而不用每次修改磁盘中的表,这会非常快.

事务日志只追加顺序I/O
WAL write-ahead logging 预写日志修改数据最终要两次磁盘写入

MySQL中的事务

描述的是InnoDB引擎中的事务

理解AUTOCOMMIT

默认开启单个语句也是包裹在事务中自动提交
可以通过set autocommit=0/1进行开关
用begin或者start transaction来开启事务
用commit提交 rollback回滚

有一些命令,当在活动的事务中发出时,会导致MySQL在事务的所有语句执行完毕前提交当前事务
比如一些DDL命令 alter table等

可以通过SET TRANSACTION ISOLATION LEVEL改变隔离级别下一个事务开始时生效

在事务中混合使用存储引擎

MySQL的事务由下层存储引擎实现
在同一个事务中,混合使用多种存储引擎是不可靠的.

隐式锁定和显式锁定

InnoDB使用两阶段锁定协议(two-phase locking protocol).
事务执行期间,随时都可以获取锁,但锁只有在提交或回滚后才会释放,并且所有的锁会同时释放.
前面描述的锁定机制都是隐式的.InnoDB会根据隔离级别自动处理锁.

显式的(不属于SQL规范)

SELECT … FOR SHARE
SELECT … FOR UPDATE

MySQL还支持LOCK TABLES和UNLOCK TABLES
这两个命令在服务器级别实现
因为InnoDB支持行级锁没必要使用

建议: 除了在禁用AUTOCOMMIT的事务中可以使用之外,其他任何时候都不要显式地执行LOCK TABLES,不管使用的是什么存储引擎.

多版本并发控制

MySQL的大多数事务型存储引擎使用的都不是简单的行级锁机制.它们会将行级锁和可以提高并发性能的多版本并发控制(MVCC)技术结合使用.

不同数据库的实现细节不一样

可以认为MVCC是行级锁的一种变种它在很多情况下避免加锁因此开销更低

通过数据快照实现

InnoDB为每个事务启动时分配一个事务ID
该事务修改记录时向Undo log写入一条如何恢复回去的undo记录事务回滚指针指向该记录
当不同会话读取聚簇主键索引记录时 InnoDB会把记录的事务ID和该会话的读取视图比较如果更改他的事务未提交则跟踪undo log直到一个符合可见条件的事务ID

大多数读取通过这种方式不需要获取锁(通过读取快照) 缺点是存储引擎会对每一行存储更多数据做更多工作

MVCC仅适用于REPEATABLE READ和READ COMMITTED隔离级别.
(可以想象对于可重复读读取的事务id固定为事务进行中第一次读的可见事务id 对于读已提交读最新的可见事务id
另外两个因为不需要事务版本(一个是脏读一个是串行化的) 和MVCC不是很适配(当然要看不同引擎的实现)