关于系统服务#

ly@tabs8:~$ ls -l /etc/systemd/system/sshd.service
lrwxrwxrwx. 1 root root 31 Apr  3 14:16 /etc/systemd/system/sshd.service（用户自定义service存放地址） -> /lib/systemd/system/ssh.service（系统安装软件后的service存放地址）

但是sudo service hello status，chroot容器中查找的只是/etc/init.d/这个路径下的hello（不查找/etc/systemd和lib/systemd中的），但是如果使用systemctl disable hello，则/etc/init.d中的hello服务不会被运行，并且会删除/etc/systemd/system/multi-user.target.wants文件夹下的软连接。如果systemctl enable hello，则会在/etc/systemd/system/multi-user.target.wants文件夹下生成一个软连接。
执行完/etc/init.d/hello就不会再操作其他东西了(hello.service没有用)

建议linuxdeploy的自动化开启Sysv模式，然后在/etc/init.d/里头编写脚本就可以了，如果要开机启动，使用systemctl enable xxx即可。

问题1#

chroot容器中，sudo systemctl enable hello.service后，开机启动时并没有执行。但是如果服务名hello在/etc/init.d/文件中存在对应名的SysV Init 脚本，就会执行，这是为什么呢

在普通 chroot 中，SysV Init 脚本能执行是因为其不依赖 PID 1 管理器，而 systemd 服务需要完整的初始化环境。若需 systemd 功能，应优先使用 systemd-nspawn。

问题2 ★#

chroot容器中，默认情况下，系统启动时会执行/etc/init.d/hello脚本（SysV Init 脚本），但是如果sudo systemctl disable hello.service后，开机启动时就不会执行了，这是为什么呢

 Debian 12（即使使用 systemd）默认保留了 SysV Init 兼容性，通过systemd-sysv-generator 工具动态生成 .service 文件来管理 /etc/init.d/ 中的脚本。当执行 systemctl disable hello.service 时：①删除符号链接：会移除 /etc/systemd/system/<target>.wants/ 中指向自动生成的 hello.service 的符号链接（如 multi-user.target.wants/hello.service）。②禁用服务：即使 /etc/init.d/hello 存在，systemd 也不会在开机时触发其执行，因为兼容层已被禁用。

systemctl enable#

ly@tabs8:~$ sudo systemctl disable ssh
Synchronizing state of ssh.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ssh
Removed "/etc/systemd/system/multi-user.target.wants/ssh.service".
Removed "/etc/systemd/system/sshd.service".
#=================================
ly@tabs8:~$ ls -l /etc/systemd/system/multi-user.target.wants | grep ssh
ly@tabs8:~$ ls -l /etc/systemd/system/ | grep ssh
#================开机自启动========
ly@tabs8:~$ sudo systemctl enable ssh
Synchronizing state of ssh.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ssh
#创建了两个符号链接
#保证兼容性，十几年前一直是用sshd
Created symlink /etc/systemd/system/sshd.service → /lib/systemd/system/ssh.service.
#multi-user.target.wants下: 开机自启动
Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service → /lib/systemd/system/ssh.service.
#开机自启动其实是直接链接到系统（软件）自己的service
ly@tabs8:~$ ls -l /etc/systemd/system/multi-user.target.wants | grep ssh
lrwxrwxrwx. 1 root root 31 Apr  3 15:05 ssh.service -> /lib/systemd/system/ssh.service
ly@tabs8:~$ ls -l /etc/systemd/system/ | grep ssh
lrwxrwxrwx. 1 root root   31 Apr  3 15:05 sshd.service -> /lib/systemd/system/ssh.service

#====总的来说，我只要在/etc/systemd/system/下创建自己的服务S，然后systemctl enable S即可

service编写(这里没用上)#

vim /etc/systemd/system/vncser

[Unit]
Description=TigerVncService  # 服务描述
After=network.target          # 定义启动顺序（在网络就绪后启动）

[Service]
Type=simple                  # 服务类型（simple/forking/oneshot等）
ExecStart=/usr/local/bin/tigervnc.sh    # 启动命令（绝对路径）
Restart=on-failure           # 失败时自动重启
User=ly                  # 运行用户（可选）
#Group=nogroup                # 运行组（可选）
#WorkingDirectory=/path/to    # 工作目录（可选）

[Install]
WantedBy=multi-user.target   # 定义服务所属的“目标”（开机自启）

一些命令暂记#

#镜像下载 https://mirrors-i.tuna.tsinghua.edu.cn/lxc-images/images/debian/bookworm/arm64/
#发行版 [rootfs.tar]
#源地址 ${EXTERNAL_STORAGE}/linuxdeploy/bookworm.tar.xz

#=====!!!!安装类型[ 目录]会有一些问题，比如ssh提示权限过高，不太懂..=======
#安装路径[ ${ENV_DIR}/rootfs/bookworm ] --> [ /data/data/ru.meefik.linuxdeploy/files/rootfs/bookworm ]----安装类型[ 目录]
#安装路径[ /data/media/0/linuxdeploy/bookworm ]----安装类型[ 目录] 
#建议放镜像
#安装路径{EXTERNAL_STORAGE}/linuxdeploy/bookworm.img----安装类型[ 镜像文件]

#用户名--用户密码--特权用户--本地化--DNS--networktrigger--powertrigger--随便弃用
#(弃用)初始化-启用-run-parts--路径/etc/rc.local--初始用户root
#!!!!初始化我这里使用sysv，通过systemctl enable ssh可以让ssh开机自启动，但是systemctl start ssh不能使用，需要用service ssh start替代
#挂载目录--挂载点--source使用/data/media/0 （data开头的，android14中其他的好像都不行不知道为什么，给ly加了 aid_media_rw  这个组权限） sudo usermod -aG  aid_media_rw username
#其他都不需要

#设置 telnet守护模式打开

挂载目录说明#

为了统一，可以用/mnt/pass_through/0/emulated/0/(内置存储卡) 以及/mnt/pass_through/0/822C-9525/(外置存储卡)

undolog#

作用#

1. 恢复某条记录原始状态
2. 记录修改过程，MVCC的原理，结合事务id知道哪些数据可见 undo log的修改本身会被记录到redo log中。即使undo log未刷盘，崩溃恢复时也可以通过redo log重建undo log。

redolog#

1. 数据持久性–事务提交后，buffer pool一些脏页没有写入数据库磁盘文件。重启时，利用redolog恢复(表空间、页号、偏移量、数值)的数据（磁盘数据）
2. 由于redolog有几种策略时机刷入磁盘。另有额外线程每隔1s不断刷入redolog buffer pool数据到redolog磁盘日志文件中，如果事务未提交但是刷入了redolog日志文件也无妨。可以根据一些标识，找到哪个事务是未提交的，然后再用undolog恢复原始状态。

root@db211:/var/lib/mysql# ls
auto.cnf	 ibdata1	     public_key.pem
ca-key.pem	 ib_logfile0 (redolog)	     server-cert.pem
ca.pem		 ib_logfile1 (redolog)		 server-key.pem
client-cert.pem  ibtmp1		     sys
client-key.pem	 mysql		     test
db211-slow.log	 performance_schema  xx
ib_buffer_pool 	 private_key.pem

update语句执行流程#

流程#

1. 事务开始
   1. 写Undo Log到Undo Log Buffer（记录旧值）
   2. 修改Buffer Pool中的数据页（生成脏页）
   3. 写Redo Log到Redo Log Buffer（记录物理变更） 修改BufferPool后，还会MySQL还会生成对应的Binlog 事件逻辑操作记录），先写入线程的私有内存缓冲区（Binlog Cache）
2. 事务提交
   1. Redo Log 标记为 Prepare
   2. 写Binlog并刷盘
   3. Redo Log Commit阶段（标记提交）

redolog的刷盘策略#

1. Redo Log Buffer 空间不足：当 Redo Log Buffer 的写入速度超过刷盘速度时，InnoDB 会强制刷盘以释放空间。
2. 后台线程定期刷盘：InnoDB 的后台线程（如 log_writer 和 log_flusher）会周期性刷盘（默认每秒一次，由 innodb_flush_log_at_timeout 控制）。
3. 参数配置触发
   1. 0：设置为 0 的时候，表示每次事务提交时不进行刷盘操作。这种方式性能最高，但是也最不安全，因为如果 MySQL 挂了或宕机了，可能会丢失最近 1 秒内的事务。
   2. 1：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作。这种方式性能最低，但是也最安全，因为只要事务提交成功，redo log 记录就一定在磁盘里，不会有任何数据丢失。
   3. 2：设置为 2 的时候，表示每次事务提交时都只把 log buffer 里的 redo log 内容写入 page cache（文件系统缓存）。page cache 是专门用来缓存文件的，这里被缓存的文件就是 redo log 文件。这种方式的性能和安全性都介于前两者中间。

这里其实有个疑问，就是redolog并不是事务提交后才刷盘的，而是很有可能事务提交前就刷盘了。如果提交前刷盘了，之后系统宕机了，那么redolog磁盘文件就多出了一些未提交事务的日志。解决办法：可以通过一些属性，在undolog中找到未提交事务的id，然后通过undolog回滚未提交事务。

关闭自动提交#

在MySQL命令行的默认设置下，事务都是自动提交的，即执行SQL语句后就会马上执行COMMIT操作。因此开始一个事务，必须使用BEGIN、START TRANSACTION，(显示开启事务）或者执行SET AUTOCOMMIT=0，以禁用当前会话的自动提交。

1. select语句一般用来输出用户变量，比如select @变量名，用于输出数据源不是表格的数据。
2. 系统变量在变量名前面有两个@

mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)

mysql> select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)
# 修改变量
set autocommit=0;

本文中autocommit=0，开始事务需要使用begin显式开启

事务并发存在的问题#

没有脏读问题，如果两个事务同时修改一条数据，那么另一个事务的修改操作会被阻塞
【隔离性】脏读（读到了还没有提交的数据）

【隔离性】不可重复读（同一事务中，第1次读的数据和第2次读的数据不一样。读到了事务操作过程中其他事务提交的数据，也不应该，这个没法保证一致性。比如我第一次根据某个事务做了一个操作，第二次想同样的逻辑做一个判断操作，但是数据变了，导致同一个事务中对同一个(其实不是了）数据做的操作居然不一致

【隔离性】虚读、幻读（同一事务中：我第一次读到某一条数据，但是第二次没读到；或者第一次没读到，第二次居然读到了。条数问题）

事务的隔离级别#

READ_UNCOMMITTED 读未提交
READ_COMMITTED 读已提交
REPEATABLE_READ 重复读 SERIALIZABLE 串行化(行锁) 修改事务隔离级别：

set tx_isolation='SERIALIZABLE'; (可以加global，让新开的session也使用该事务隔离级别)

经测试，如果有三个session（mysql客户端），其中一个(a)是SERIALIZABLE,而其他两个(b,c)是READ_UNCOMMITTED，那么客户端b,c之间不会因为锁挂起，而ab或ac会导致(行)锁挂起

REPEATABLE_READ重复读#

REPEATABLE_READ重复读的隔离级别只能在一定程度上防止幻读 如果事务a(插入一条新数据，或者删除一条数据)后提交。那么变动的数据不会在事务b被查出来。但是如果插入的这条数据(在事务b，注意 不是事务a)被修改了，那么之后它会在事务b被查出来

新增后修改#

事务a新增数据后提交，在事务b执行中修改了该数据，则该数据会显示出来（影响了）

#=======事务b=======
mysql> begin;
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
|  1 |  10 |
|  2 |  20 |
|  3 |  33 |
+----+-----+
#=======事务a=======
mysql> insert into user(age) values(44);
#=======事务b=======
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
|  1 |  10 |
|  2 |  20 |
|  3 |  33 |
+----+-----+
#=======事务a=======
mysql> update user set age=55 where id = 4;
#=======事务b=======
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
|  1 |  10 |
|  2 |  20 |
|  3 |  33 |
+----+-----+
#=======事务b=======
mysql> update user set age=55 where id = 4;
mysql> select * from user;
+----+-----+
| id | age |
+----+-----+
|  1 |  10 |
|  2 |  20 |
|  3 |  33 |
|  4 |  55 |
+----+-----+
##此时如果事务a进行 delete from user where id = 4; 那么事务a会阻塞，直到事务b commit

删除后修改#

事务a删除数据后提交，在事务b执行中修改了该数据，该数据也照样存在（不影响）

表结构、数据、索引

文件目录#

 root@db211:/var/lib/mysql/mysql# ls | tail -16
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
time_zone.frm
time_zone.ibd
time_zone_leap_second.frm
time_zone_leap_second.ibd
time_zone_name.frm
time_zone_name.ibd
time_zone_transition.frm
time_zone_transition.ibd
time_zone_transition_type.frm   #INNODB存储引擎-表结构
time_zone_transition_type.ibd   #INNODB存储引擎-表数据+表索引（包括所有索引）
user.frm   #MyISAM存储引擎-表结构
user.MYD   #MyISAM存储引擎-表数据
user.MYI   #MyISAM存储引擎-表索引

INNODE存储引擎的表主键聚簇索引和数据在同一个文件（所以即使没有设置主键，innodb也会为每一行自动生成一个默认的隐藏主键列，用来形成B+树）

索引#

索引创建#

建表时创建#

create table index1( id int, name varchar(20), index idx_id_name (id,name));

后续添加#

create index idx_name on bank_bill (name);

B树#

m阶B树 ,m个分支（或者说m个区间）
x个元素就会有x+1个区间

B+树和B树区别#

从B树考虑#

log2 2000万≈24.3 log500 2000万≈3 (m阶平衡树) 如果是500阶B树，那么2000万个节点最多只需要3层

从B+树考虑#

MySQL中，一个节点1页，也就是16KB（可以改），而一个节点可以放（主键bigint(8字节)+页号地址 6字节)单元1170个，假设是1000，那两层可以放100 0000万个节点。由于1个节点16KB，如果一条数据用1KB的话，那么最底层每个叶子节点就是放16条数据。那就是3层可以放1600万条数据。这是估算，细算的话应该是2000万左右

其他#

操作系统内存管理按页面4K为单位。MySQL默认使用InnoDB存储引擎，其数据块大小（block size）一般默认为16KB

using index#

mysql> explain select name from student where name = 'liuxiang' \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: student
   partitions: NULL
         type: ref
possible_keys: idx_name
          key: idx_name
      key_len: 152
          ref: const
         rows: 1
     filtered: 100.00
        Extra: Using index (直接在二级索引搜索就结束了)

下面这个还需要回表

分类#

• DDL 数据定义语言(create,drop,alter)
• DML 数据操纵语言(insert,delete,update,select)
• DCL 数据控制语言(grant,revoke)

删除#

mysql> select * from user;
+----+----------+-----+-----+
| id | name     | age | sex |
+----+----------+-----+-----+
|  1 | zhangsan |  20 | M   |
|  2 | wuqi     |  34 | M   |
|  5 | baobaoi  |  45 | W   |
|  6 | lalal    |  44 | W   |
+----+----------+-----+-----+
4 rows in set (0.00 sec)
mysql> delete from user where id = 6
#如果之后重启了mysql（且id最大为5，则再插入的数据id为6），（如果id最大为10，则插入的数据id为11）；如果没有重启，则再插入的数据id为7
mysql> nsert into user(name,age,sex) values('hah',35,'W');

新增#

一次新增多条数据和多次新增单条数据区别

搜索#

limit可以优化sql语句，不过要看数据的位置

mysql> select * from t_user  limit 1999999 ,1;
+---------+------------------+------------+
| id      | email            | password   |
+---------+------------------+------------+
| 2000000 | cwng78@yahoo.com | h4HcxZKBNQ |
+---------+------------------+------------+
1 row in set (0.52 sec)
#这条数据在最后一条，所以优化效果不怎么样
mysql> select * from t_user where email='cwng78@yahoo.com';
+---------+------------------+------------+
| id      | email            | password   |
+---------+------------------+------------+
| 2000000 | cwng78@yahoo.com | h4HcxZKBNQ |
+---------+------------------+------------+
1 row in set (0.47 sec)

在第一条或者前面，则优化效果显著

本课程大纲#

部分扩展知识#

MySQL分为服务端和客户端（两进程），SQLite是进程程序，客户端和服务端都在同一个进程操作数据

安装(windows)#

安装目录下包括数据目录(Data/)和配置文件(my.ini)

安装(debian)#

数据目录#

root@db211:/etc/mysql# ls -l /var/lib/mysql | awk '{print $1,$3,$4,$9}'
total   
-rw-r----- mysql mysql auto.cnf
-rw------- mysql mysql ca-key.pem
-rw-r--r-- mysql mysql ca.pem
-rw-r--r-- mysql mysql client-cert.pem
-rw------- mysql mysql client-key.pem
-rw-r----- mysql mysql ib_buffer_pool
-rw-r----- mysql mysql ibdata1
-rw-r----- mysql mysql ib_logfile0
-rw-r----- mysql mysql ib_logfile1
-rw-r----- mysql mysql ibtmp1
drwxr-x--- mysql mysql mysql
drwxr-x--- mysql mysql performance_schema
-rw------- mysql mysql private_key.pem
-rw-r--r-- mysql mysql public_key.pem
-rw-r--r-- mysql mysql server-cert.pem
-rw------- mysql mysql server-key.pem
drwxr-x--- mysql mysql sys
drwxr-x--- mysql mysql xx

配置目录#

root@db211:/etc/mysql# ls -l | awk '{print $1,$9,$10,$11}'
total   
drwxr-xr-x conf.d  
lrwxrwxrwx my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- my.cnf.fallback  
-rw-r--r-- mysql.cnf  
drwxr-xr-x mysql.conf.d

再进一步查看

概述#

计算机为了运行程序，会执行一串独立的指令
两种形式的机器语言：

1. 在计算机上运行的实际目标代码（字节，二进制01）
2. 汇编代码（编译器的目标，文本格式）

不写汇编，但需要学习：

1. 编译器产生的结果（汇编及目标代码）与文本代码关联
2. 低级代码（汇编、二进制）如何实现高级别程序构造
3. 过程函数、结构体、数组在机器语言中的实现

课程选择64位版本的Intel指令集
为什么叫x86处理器16位微处理器(也称CISC复杂，与之对应的是RISC精简)，因为一开始的处理器是8086，接着8286,8386…
需要更加关注–gcc编译生成的代码长什么样

x86进化#

多核处理器#

另一个公司：AMD

教学范围#

哪些处理器#

• ARM(AcornRISCMachine)，比x86机器功耗更低
• x86

定义#

• 指令集
• 寄存器：非常小的内存位置
• 机器指令
  

（无法直接操作缓存(没有这个概念），是机器级别的概念)

将c源代码转换成目标文件#

汇编简介#

gcc -Og -S sum.c #-Og 调试级别的优化过的（英文字母大写O)； -S 生成汇编 

带点的这些，是给调试器用的(用来定位)；也有一些是给链接器用（告诉它这是个全局定义的函数）

数据类型#

1. 多种整数数据类型（不区分符号与无符号，都以数字形式存储在计算机）
2. 浮点（使用和整型不一样的寄存器组）
3. 程序本身在x86中，是一系列字节
4. 没有数组或结构，由编译器人工处理

指令#

每条指令做的事很有限（只做一件小事）

反汇编#

举例#

• 变量的概念在汇编级别代码中完全消失（变成了寄存器或内存中某个东西）

使用gdb反汇编#

第26章 写作本书时用到的一些重要的参考资料

感谢#

我不生产知识，只是知识的搬运工。写作本小册的时间主要用在了两个方面：

搞清楚事情的本质是什么。

这个过程就是研究源码、书籍和资料。

如何把我已经知道的知识表达出来。

这个过程就是我不停的在地上走过来走过去，梳理知识结构，斟酌用词用句，不停的将已经写好的文章推倒重来，只是想给大家一个不错的用户体验。

这两个方面用的时间基本上是一半一半吧，在搞清楚事情的本质是什么阶段，除了直接阅读MySQL的源码之外，查看参考资料也是一种比较偷懒的学习方式。本书只是MySQL进阶的一个入门，想了解更多关于MySQL的知识，大家可以从下面这些资料里找点灵感。

一些链接#

MySQL官方文档： https://dev.mysql.com/doc/refman/5.7/en/

MySQL官方文档是写作本书时参考最多的一个资料。说实话，文档写的非常通俗易懂，唯一的缺点就是太长了，导致大家看的时候无从下手。

MySQL Internals Manual： https://dev.mysql.com/doc/internals/en/

介绍MySQL如何实现各种功能的文档，写的比较好，但是太少了，有很多章节直接跳过了。

何登成的github： https://github.com/hedengcheng/tech

登博的博客非常好，对事务、优化这讨论的细节也非常多，不过由于大多是PPT结构，字太少，对上下文不清楚的同学可能会一脸懵逼。

orczhou的博客： http://www.orczhou.com/

Jeremy Cole的博客： https://blog.jcole.us/innodb/

Jeremy Cole大神不仅写作了innodb_ruby这个非常棒的解析InnoDB存储结构的工具，还对这些存储结构写了一系列的博客，在我几乎要放弃深入研究表空间结构的时候，是他老人家的博客把我又从深渊里拉了回来。

那海蓝蓝（李海翔）的博客： https://blog.csdn.net/fly2nn

taobao月报： http://mysql.taobao.org/monthly/

因为MySQL的源码非常多，经常让大家无从下手，而taobao月报就是一个非常好的源码阅读指南。

吐槽一下，这个taobao月报也只能当作源码阅读指南看，如果真的不看源码光看月报，那只能当作天书看，十有八九被绕进去出不来了。

MySQL Server Blog： http://mysqlserverteam.com/

MySQL team的博客，一手资料，在我不知道看什么的时候给了很多启示。

mysql_lover的博客： https://blog.csdn.net/mysql_lover/

• Jorgen’s point of view： https://jorgenloland.blogspot.com/

mariadb的关于查询优化的文档： https://mariadb.com/kb/en/library/query-optimizations/

不得不说mariadb的文档相比MySQL的来说就非常有艺术性了（里边儿有很多漂亮的插图），我很怀疑MySQL文档是程序员直接写的，mariadb的文档是产品经理写的。当我们想研究某个功能的原理，在MySQL文档干巴巴的说明中找不到头脑时，可以参考一下mariadb娓娓道来的风格。

Reconstructing Data Manipulation Queries from Redo Logs： https://www.sba-research.org/wp-content/uploads/publications/WSDF2012_InnoDB.pdf

• 关于InnoDB事务的一个PPT： https://mariadb.org/wp-content/uploads/2018/02/Deep-Dive_-InnoDB-Transactions-and-Write-Paths.pdf

非官方优化文档： http://www.unofficialmysqlguide.com/optimizer-trace.html

这个文档非常好，非常非常好～

MySQL8.0的源码文档： https://dev.mysql.com/doc/dev/mysql-server

一些书籍#

《数据库查询优化器的艺术》李海翔著

大家可以把这本书当作源码观看指南来看，不过讲的是5.6的源码，5.7里重构了一些，不过大体的思路还是可以参考的。

《MySQL运维内参》周彦伟、王竹峰、强昌金著

第25章 工作面试老大难-锁

解决并发事务带来问题的两种基本方式#

上一章介绍了事务并发执行时可能带来的各种问题，并发事务访问相同记录的情况大致可以划分为3种：

读-读情况：即并发事务相继读取相同的记录。

读取操作本身不会对记录有一毛钱影响，并不会引起什么问题，所以允许这种情况的发生。

写-写情况：即并发事务相继对相同的记录做出改动。

我们前面说过，在这种情况下会发生脏写的问题，任何一种隔离级别都不允许这种问题的发生。所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行，这个排队的过程其实是通过锁来实现的。这个所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是说一开始是没有锁结构和记录进行关联的，如图所示：

当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的锁结构，当没有的时候就会在内存中生成一个锁结构与之关联。比方说事务T1要对这条记录做改动，就需要生成一个锁结构与之关联：

其实在锁结构里有很多信息，不过为了简化理解，我们现在只把两个比较重要的属性拿了出来： - trx信息：代表这个锁结构是哪个事务生成的。 - is_waiting：代表当前事务是否在等待。

如图所示，当事务T1改动了这条记录后，就生成了一个锁结构与该记录关联，因为之前没有别的事务为这条记录加锁，所以is_waiting属性就是false，我们把这个场景就称之为获取锁成功，或者加锁成功，然后就可以继续执行操作了。

在事务T1提交之前，另一个事务T2也想对该记录做改动，那么先去看看有没有锁结构与这条记录关联，发现有一个锁结构与之关联后，然后也生成了一个锁结构与这条记录关联，不过锁结构的is_waiting属性值为true，表示当前事务需要等待，我们把这个场景就称之为获取锁失败，或者加锁失败，或者没有成功的获取到锁，画个图表示就是这样：

在事务T1提交之后，就会把该事务生成的锁结构释放掉，然后看看还有没有别的事务在等待获取锁，发现了事务T2还在等待获取锁，所以把事务T2对应的锁结构的is_waiting属性设置为false，然后把该事务对应的线程唤醒，让它继续执行，此时事务T2就算获取到锁了。效果图就是这样：

我们总结一下后续内容中可能用到的几种说法，以免大家混淆：

+  

不加锁

意思就是不需要在内存中生成对应的锁结构，可以直接执行操作。

+  

获取锁成功，或者加锁成功

意思就是在内存中生成了对应的锁结构，而且锁结构的is_waiting属性为false，也就是事务可以继续执行操作。

+  

获取锁失败，或者加锁失败，或者没有获取到锁

意思就是在内存中生成了对应的锁结构，不过锁结构的is_waiting属性为true，也就是事务需要等待，不可以继续执行操作。

小贴士：这里只是对锁结构做了一个非常简单的描述，我们后边会详细介绍介绍锁结构的，稍安勿躁。

读-写或写-读情况：也就是一个事务进行读取操作，另一个进行改动操作。

我们前面说过，这种情况下可能发生脏读、不可重复读、幻读的问题。

小贴士：幻读问题的产生是因为某个事务读了一个范围的记录，之后别的事务在该范围内插入了新记录，该事务再次读取该范围的记录时，可以读到新插入的记录，所以幻读问题准确的说并不是因为读取和写入一条相同记录而产生的，这一点要注意一下。

SQL标准规定不同隔离级别下可能发生的问题不一样： - 在READ UNCOMMITTED隔离级别下，脏读、不可重复读、幻读都可能发生。 - 在READ COMMITTED隔离级别下，不可重复读、幻读可能发生，脏读不可以发生。 - 在REPEATABLE READ隔离级别下，幻读可能发生，脏读和不可重复读不可以发生。 - 在SERIALIZABLE隔离级别下，上述问题都不可以发生。

不过各个数据库厂商对SQL标准的支持都可能不一样，与SQL标准不同的一点就是，MySQL在REPEATABLE READ隔离级别实际上就已经解决了幻读问题。

怎么解决脏读、不可重复读、幻读这些问题呢？其实有两种可选的解决方案：

+  

方案一：读操作利用多版本并发控制（MVCC），写操作进行加锁。

所谓的MVCC我们在前一章有过详细的描述，就是通过生成一个ReadView，然后通过ReadView找到符合条件的记录版本（历史版本是由undo日志构建的），其实就像是在生成ReadView的那个时刻做了一次时间静止（就像用相机拍了一个快照），查询语句只能读到在生成ReadView之前已提交事务所做的更改，在生成ReadView之前未提交的事务或者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用MVCC时，读-写操作并不冲突。

小贴士：我们说过普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录。在READ COMMITTED隔离级别下，一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView，ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现象；REPEATABLE READ隔离级别下，一个事务在执行过程中只有第一次执行SELECT操作才会生成一个ReadView，之后的SELECT操作都复用这个ReadView，这样也就避免了不可重复读和幻读的问题。

+  

方案二：读、写操作都采用加锁的方式。

第24章 一条记录的多幅面孔-事务的隔离级别与MVCC

事前准备#

为了故事的顺利发展，我们需要创建一个表： CREATE TABLE hero ( number INT, name VARCHAR(100), country varchar(100), PRIMARY KEY (number) ) Engine=InnoDB CHARSET=utf8; 小贴士：注意我们把这个hero表的主键命名为number，而不是id，主要是想和后边要用到的事务id做区别，大家不用大惊小怪～ 然后向这个表里插入一条数据： INSERT INTO hero VALUES(1, '刘备', '蜀'); 现在表里的数据就是这样的： mysql> SELECT * FROM hero; +--------+--------+---------+ | number | name | country | +--------+--------+---------+ | 1 | 刘备 | 蜀 | +--------+--------+---------+ 1 row in set (0.00 sec)

事务隔离级别#

我们知道MySQL是一个客户端／服务器架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称之为一个会话（Session）。每个客户端都可以在自己的会话中向服务器发出请求语句，一个请求语句可能是某个事务的一部分，也就是对于服务器来说可能同时处理多个事务。在事务简介的章节中我们说过事务有一个称之为隔离性的特性，理论上在某个事务对某个数据进行访问时，其他事务应该进行排队，当该事务提交之后，其他事务才可以继续访问这个数据。但是这样子的话对性能影响太大，我们既想保持事务的隔离性，又想让服务器在处理访问同一数据的多个事务时性能尽量高些，鱼和熊掌不可得兼，舍一部分隔离性而取性能者也。

事务并发执行遇到的问题#

怎么个舍弃法呢？我们先得看一下访问相同数据的事务在不保证串行执行（也就是执行完一个再执行另一个）的情况下可能会出现哪些问题：

脏写（Dirty Write）

如果一个事务修改了另一个未提交事务修改过的数据，那就意味着发生了脏写，示意图如下：

如上图，Session A和Session B各开启了一个事务，Session B中的事务先将number列为1的记录的name列更新为'关羽'，然后Session A中的事务接着又把这条number列为1的记录的name列更新为张飞。如果之后Session B中的事务进行了回滚，那么Session A中的更新也将不复存在，这种现象就称之为脏写。这时Session A中的事务就很懵逼，我明明把数据更新了，最后也提交事务了，怎么到最后说自己什么也没干呢？