1.2 并发控制

无论何时，只要有多个查询需要在同一时刻修改数据，就会产生并发控制的问题。

MySQL提供锁来防止数据损坏，但是这种方案并不支持并发处理。

1.2.1 读写锁

　　 共享锁（Shared），简写为 S 锁，又称读锁。是共享的，或者说是相互不阻塞的。多个客户在同一时刻可以同时读取同一个资源，而互不干扰。

    　排它锁（Exclusive），简写为 X 锁，又称写锁。是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑，只有这样，才能确保在给定的时间里，只有一个用户能执行写入，并防止其他用户读取正在写入的同一资源。    

　　有以下两个规定：

• 一个事务对数据对象 A 加了 X 锁，就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。
• 一个事务对数据对象 A 加了 S 锁，可以对 A 进行读取操作，但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁，但是不能加 X 锁。

1.2.2 锁粒度

　　MySQL 中提供了两种封锁粒度：行级锁以及表级锁。

　　应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高。

　　但是加锁需要消耗资源，锁的各种操作（包括获取锁、释放锁、以及检查锁状态）都会增加系统开销。因此封锁粒度越小，系统开销就越大。

　　在选择封锁粒度时，需要在锁开销和并发程度之间做一个权衡。

　　1. 表锁（table lock）是MySQL中最基本的锁策略，并且是开销最小的策略。它会锁定整张表。一个用户在对表进行写操作（插入、删除、更新等）前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。

　　2. 行级锁（row lock）可以最大程度地支持并发处理（同时也带来了最大的锁开销）。在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务器层没有实现。服务器层完全不了解存储引擎中的锁实现。

1.2.3 MySQL 隐式与显示锁定

MySQL 的 InnoDB 存储引擎采用两段锁协议。在事物执行的过程中，随时都可以执行锁定，锁只有在执行COMMIT或者ROLLBACK的时候才会释放。InnoDB会根据隔离级别在需要的时候自动加锁，并且所有的锁都是在同一时刻被释放，这被称为隐式锁定。之前描述的锁定都是隐式锁定

InnoDB 也可以使用特定的语句进行显示锁定：

SELECT ... LOCK In SHARE MODE;
SELECT ... FOR UPDATE;

转载于:https://www.cnblogs.com/xlzfdddd/p/10094306.html