啊~数据库、操作系统、计算机网络、Linux

start

操作系统

并发和并行

并发是同一时间段内发生了多个事情，多任务之间互相抢占资源。

并行是在同一时间点内发生了多个事情，多任务之间不互相抢占资源，只有多CPU的情况下才能并行。

例如：我今天同时学习了数据库、操作系统、计算机网络和Linux这四门课程，学四门课程的任务是并发执行的。我和我的小伙伴两个人（相当于多CPU），今天同时学习了四大件，但是某一时刻我俩同时学习了操作系统这门课程，这一时刻下的学习叫并行。

数据库

MySQL锁

用于解决多个事务在并发情况下的脏读、不可重复读、幻读、丢失更新。

查了一下王珊老师的《数据库系统概论》第5版，310页。

脏读：事务T1修改某一数据并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤销，这时被T1修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为“脏”数据，即不正确的数据。

丢失更新：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。

不可重复读：事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。

幻读：不可重复读的另外两种现象。1）事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神秘地消失了。2）事务按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。

锁的种类

全局锁：对整个数据库加锁。（全库逻辑备份）(数据增删改查× 建表、修改表结构× 更新类事务的提交×)

Flush tables with read lock(FTWRL)

表级锁

（1）表锁：（每次操作锁住整张表 开销小，加锁快 并发度低）

lock tables ...read/write

元数据锁（MDL）访问表时自动被加上，保持读写的正确性。事务提交后释放，可能会产生死锁问题。

（2）行锁：针对数据表中行记录的锁（每次操作锁住一行数据 开销大，加锁慢 锁冲突低，并发度高）

加锁规则：2原则、2优化、1bug

2原则：1）加锁基本单位next-key lock，前开后闭

             2）查找过程中访问到的对象才会加锁

2优化：1）索引上的等值查询，给唯一索引加锁时，next-key lock退化为行锁

             2）索引上的等值查询，向右遍历时且最后一个值不满足等值条件时，next-key lock退化为间隙锁

1bug：唯一的索引上的范围查询会访问到不满足条件的第一个值为止

锁的划分

1、从数据库角度

共享锁（读锁 S锁）

可被其他用户读取，但不能修改

select user_id from product_comment where user_id = 10 lock in share mode;

排它锁（写锁 X锁）

只允许进行锁定操作的事务使用，其他事务无法查询和修改

对数据库进行更新时（insert、update、delete），自动使用排它锁

select user_id from product_comment where user_id = 10 for update;

all

还可以锁住一张表

lock table product_comment read; //添加共享锁
unlock table; //解锁
lock table product_comment write; //添加排它锁
unlock table; //解锁

意向锁：给更大一级别的空间示意里面是否已经上过锁。

2、程序员角度

乐观锁：对同一数据的并发操作不会总发生，不用每次都上锁。（不采用数据库的锁机制，通过程序上，版本号或时间戳实现）（适合读操作多的场景，优点：程序实现不存在死锁问题）

悲观锁：对数据被其他事务修改保持保守态度。（通过数据库自身锁机制实现 ）（适合写操作多的场景，缺点：加锁时间长，并发性不好）

InnoDB使用表锁还是行锁？

绝大多数情况下使用行锁。使用表锁：1）表大，事务需要更新全部或大部分数据2）事务涉及多个表，比较复杂，可能引起死锁，造成大量的事务回滚。

InnoDB事务遵从两级锁协议，需要添加行锁，事务结束时释放。

封锁协议：

一级封锁协议（丢失更新）：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放

二级封锁协议（丢失更新、脏读）：在一级封锁协议基础上增加事务T在读取数据R之前必须对其加S锁，读完之后即可释放S锁

三级封锁协议（丢失更新、脏读、不可重复读）：在一级封锁协议基础上增加事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放