Mysql锁：
要在多线程环境下确保数据的准确性，通常需要使用同步机制。同步就相当于是加锁。锁的作用在于当一个线程正在操作数据时，其他线程需要等待，这可以带来以下好处。当一个线程执行完毕后，释放锁。其他线程才能进行操作！
那么我们的MySQL数据库中的锁的功能也是类似的，处理事务的隔离性中，可能会出现脏读、不可重复读、幻读的问题，所以，锁的作用也可以解决这些问题！
在数据库中，数据是一种供许多用户共享访问的资源，如何保证数据并发访问的一致性、有效性，是所有数据库必须解决的一个问题，MySQL由于自身架构的特点，在不同的存储引擎中，都设计了面对特定场景的锁定机制，所以引擎的差别，导致锁机制也是有很大差别的。
锁机制 :
数据库为了保证数据的一致性，而使用各种共享的资源在被并发访问时变得有序所设计的一种规则。
举例：在电商网站购买商品时，商品表中只存有1个商品，而此时又有两个人同时购买，那么谁能买到就是一个关键的问题。
这里会用到事务进行一系列的操作：
先从商品表中取出物品的数据
然后插入订单
付款后，再插入付款表信息
更新商品表中商品的数量
以上过程中，使用锁可以对商品数量数据信息进行保护，实现隔离，即只允许第一位用户完成整套购买流程，而其他用户只能等待，这样就解决了并发中的矛盾问题。
锁的分类：
按操作分类：
共享锁：也叫读锁。多个事务可以同时对同一份数据进行读取操作，并同时加锁以避免互相影响，但是不能对数据记录进行修改。
排他锁：也叫写锁。当前的操作没有完成前,会阻断其他操作的读取和写入
按粒度分类：
表级锁：操作时，会锁定整个表。开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低。偏向于MyISAM存储引擎！
行级锁：操作时，会锁定当前操作行。高并发情况下，锁定粒度小，有利于降低锁冲突概率，但需要注意加锁操作的速度，避免开销过大，且必须避免死锁的出现。偏向于InnoDB存储引擎！
页级锁：锁的粒度、发生冲突的概率和加锁的开销介于表锁和行锁之间，会出现死锁，并发性能一般。
按使用方式分类：
悲观锁：每次查询数据时都认为别人会修改，很悲观，所以查询时加锁。
乐观锁：每次查询数据时都认为别人不会修改，很乐观，但是更新时会判断一下在此期间别人有没有去更新这个数据
不同存储引擎支持的锁
共享锁:
多个共享锁之间可以共享，如果是有键的话InnoDB默认是行锁，没有的话就会提升到表锁，是行锁时多个窗口可以修改不同行的数据，同行的话需要等先加锁的提交，不同行可以直接修改，但是另外一个要查询也要等后面修改的提交。提交完锁就消失了
共享锁：
SELECT语句 LOCK IN SHARE MODE;
窗口1：
- 窗口1
/*
共享锁：数据可以被多个事务查询，但是不能修改
*/
-- 开启事务
START TRANSACTION;
-- 查询id为1的数据记录。加入共享锁
SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE;
-- 查询分数为99分的数据记录。加入共享锁
SELECT * FROM student WHERE score=99 LOCK IN SHARE MODE;
-- 提交事务
COMMIT;窗口2：
-- 窗口2 -- 开启事务 START TRANSACTION; -- 查询id为1的数据记录(普通查询，可以查询) SELECT * FROM student WHERE id=1; -- 查询id为1的数据记录，并加入共享锁(可以查询。共享锁和共享锁兼容) SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; -- 修改id为1的姓名为张三三(不能修改，会出现锁的情况。只有窗口1提交事务后，才能修改成功) UPDATE student SET NAME='张三三' WHERE id = 1; -- 修改id为2的姓名为李四四(修改成功，InnoDB引擎默认是行锁) UPDATE student SET NAME='李四四' WHERE id = 2; -- 修改id为3的姓名为王五五(修改失败，InnoDB引擎如果不采用带索引的列加锁。则会提升为表锁) UPDATE student SET NAME='王五五' WHERE id = 3; -- 提交事务 COMMIT;
排他锁：
在排他锁执行的时候，其他事务普通查询可以，不可以加锁任何操作
-- 标准语法 SELECT语句 FOR UPDATE;
窗口1：
-- 窗口1
/*
排他锁：加锁的数据，不能被其他事务加锁查询或修改
*/
-- 开启事务
START TRANSACTION;
-- 查询id为1的数据记录，并加入排他锁
SELECT * FROM student WHERE id=1 FOR UPDATE;
-- 提交事务
COMMIT;窗口2：
-- 窗口2 -- 开启事务 START TRANSACTION; -- 查询id为1的数据记录(普通查询没问题) SELECT * FROM student WHERE id=1; -- 查询id为1的数据记录，并加入共享锁(不能查询。因为排他锁不能和其他锁共存) SELECT * FROM student WHERE id=1 LOCK IN SHARE MODE; -- 查询id为1的数据记录，并加入排他锁(不能查询。因为排他锁不能和其他锁共存) SELECT * FROM student WHERE id=1 FOR UPDATE; -- 修改id为1的姓名为张三(不能修改，会出现锁的情况。只有窗口1提交事务后，才能修改成功) UPDATE student SET NAME='张三' WHERE id=1; -- 提交事务 COMMIT;
MyISAM锁：
MyISAM读锁：
myisam是加整个表的锁，读锁的时候，不解锁的话所有的事务可以查，不可以有其他任何操作包括本身事务也不可以操作
-- 加锁 LOCK TABLE 表名 READ; -- 解锁(将当前会话所有的表进行解锁) UNLOCK TABLES;
MyISAM写锁：
写锁的时候，只要不解锁其他事务不可以执行任何操作，本身事务可以操作
-- 标准语法 -- 加锁 LOCK TABLE 表名 WRITE; -- 解锁(将当前会话所有的表进行解锁) UNLOCK TABLES;
悲观锁：
就是很悲观，它对于数据被外界修改的操作持保守态度，认为数据随时会修改。
整个数据处理中需要将数据加锁。悲观锁一般都是依靠关系型数据库提供的锁机制。
行锁，表锁不论是读写锁都是悲观锁。
乐观锁：
就是很乐观，每次自己操作数据的时候认为没有人会来修改它，所以不去加锁。
但是在更新的时候会去判断在此期间数据有没有被修改。
需要用户自己去实现，不会发生并发抢占资源，只有在提交操作的时候检查是否违反数据完整性。
乐观锁的简单实现方式：
实现思想：加标记去比较，一样则执行，不同则不执行
方式一：版本号
给数据表中添加一个version列，每次更新后都将这个列的值加1。
读取数据时，将版本号读取出来，在执行更新的时候，比较版本号。
如果相同则执行更新，如果不相同，说明此条数据已经发生了变化。
用户自行根据这个通知来决定怎么处理，比如重新开始一遍，或者放弃本次更新。
-- 创建city表
CREATE TABLE city(
id INT PRIMARY KEY AUTO_INCREMENT, -- 城市id
NAME VARCHAR(20), -- 城市名称
VERSION INT -- 版本号
);
-- 添加数据
INSERT INTO city VALUES (NULL,'北京',1),(NULL,'上海',1),(NULL,'广州',1),(NULL,'深圳',1);
-- 修改北京为北京市
-- 1.查询北京的version
SELECT VERSION FROM city WHERE NAME='北京';
-- 2.修改北京为北京市，版本号+1。并对比版本号
UPDATE city SET NAME='北京市',VERSION=VERSION+1 WHERE NAME='北京' AND VERSION=1;方式二：时间戳
和版本号方式基本一样，给数据表中添加一个列，名称无所谓，数据类型需要是timestamp
每次更新后都将最新时间插入到此列。
读取数据时，将时间读取出来，在执行更新的时候，比较时间。
如果相同则执行更新，如果不相同，说明此条数据已经发生了变化。
悲观锁和乐观锁使用前提：
当读取操作远多于写操作时，更新操作被加锁会阻塞所有读取操作，降低了系统的吞吐量。最后还要释放锁，锁是需要一些开销的，这时候可以选择乐观锁。
如果是读写比例差距不是非常大或者系统没有响应不及时，吞吐量瓶颈的问题，那就不要去使用乐观锁，它增加了复杂度，也带来了业务额外的风险。这时候可以选择悲观锁。
