MySQL是一个关系型数据库管理系统,由瑞典MySQL AB公司开发,属于Oracle旗下产品,是最流行的关系型数据库管理系统之一.
表很多时,使用linux脚本,需要根据需要修改一下：
和创建一样,可以加上 if exists
可两篇文章：
如：
用于在已有的表中添加、删除或修改列.
添加 ADD
或
默认是添加到最后,但可以指定位置. FIRST ：添加最前
AFTER 字段名 ：添加指定字段之后
例子：
删除 DROP
修改 MODIFY 主要修改原列的类型或约束条件 同样可以用 FIRST 和 AFTER 字段名 ,代表的是修改到哪里.
修改字段名 CHANGE
单行
多行,注意 只有一个VALUES ：
除了以上方法外,还可以用SET为每一行附上相应的值.
假如没有筛选的话,就给全部都修改了.可以用 WHERE 筛选.
假如 没有筛选的话,就给全部删除了 .相当于清空.
清空
先把表删除,然后再建一个.与 DELETE FROM 相比, TRUNCATE 的效率更快,因为 DELETE FROM 是把记录逐条删除的.
查询执行的顺序
FROM -- WHERE -- SELECT -- GROUP BY -- HAVING -- ORDER BY -- LIMIT
注意
当数据很大,上百万的时候,使用LIMIT ... OFFSET ..的方式进行分页十分浪费资源且耗时长.最好是结合WHERE使用,如：
REGEXP 使用正则表达进行匹配. 查询时,需要搭配WHERE或HAVING使用 .
两个表之间有交集且要用到两个表的数据时,可以使用内连接查询.
用法：
但 MySQL中不支持 FULL OUTER JOIN .
即SELECT嵌套.
IN 一个查询结果作为另一个查询的条件. 如：
EXISTS 用于判断查询子句是否有记录,如果有一条或多条记录存在返回 True,否则返回 False.True时执行. 如：
索引的本质是一种排好序的数据结构.利用索引可以提高查询速度.
常见的索引有：
MySQL通过外键约束来保证表与表之间的数据的完整性和准确性. 外键的使用条件：
外键的好处：可以使得两张表关联,保证数据的一致性和实现一些级联操作.
对已有的两个表增加外键 比如：主表为A,子表为B,外键为aid,外键约束名字为a_fk_b
为子表添加一个字段,当做外键
为子表添加外键约束条件
这是因为MySQL中设置了foreign key关联,造成无法更新或删除数据.可以通过设置 FOREIGN_KEY_CHECKS 变量来避免这种情况. 第一步：禁用外键约束,我们可以使用： SETFOREIGN_KEY_CHECKS=0; 第二步：删除数据 第三步：启动外键约束,我们可以使用： SETFOREIGN_KEY_CHECKS=1; 查看当前FOREIGN_KEY_CHECKS的值,可用如下命令： SELECT @@FOREIGN_KEY_CHECKS;
使用 UNION 来组合两个查询,如果第一个查询返回 M 行,第二个查询返回 N 行,那么组合查询的结果一般为 M+N 行.
每个查询必须包含相同的列、表达式和聚集函数.
默认会去除相同行,如果需要 保留 相同行,使用 UNION ALL .
只能包含一个 ORDER BY 子句,并且必须位于语句的最后 .
内置函数很多, 见: MySQL 函数
我们一般使用 START TRANSACTION 或 BEGIN 开启事务, COMMIT 提交事务中的命令, SAVEPOINT : 相当于设置一个还原点, ROLLBACK TO : 回滚到某个还原点下
一般的使用格式如下:
开启事务时, 默认加锁
根据类型可分为共享锁（SHARED LOCK）和排他锁（EXCLUSIVE LOCK）或者叫读锁（READ LOCK）和写锁（WRITE LOCK）.
根据粒度划分又分表锁和行锁.表锁由数据库服务器实现,行锁由存储引擎实现.
除此之外,我们可以显示加锁
加锁时, 如果没有索引,会锁表,如果加了索引,就会锁行
InnoDB默认支持行锁,获取锁是分步的,并不是一次性获取所有的锁,所以呢在锁竞争的时候就会出现死锁的情况
解决方法:
即ACID特性:
由于并发事务会引发上面这些问题, 我们可以设置事务的隔离级别解决上面的问题.
MySQL的默认隔离级别（可重复读）
查看当前会话隔离级别
方式1
设置隔离级别
主从集群的示意图如下:
主要涉及三个线程： binlog 线程、 I/O 线程和 SQL 线程.
同步流程:
由于MySQL主从集群只会从主节点同步到从节点, 不会反过来同步, 所以需要读写分离
读写分离需要在业务层面实现 , 写数据只能在主节点上完成, 而读数据可以在主节点或从节点上完成
索引是帮助MySQL高效获取数据的排好序的数据结构
MySQL的索引有
推荐两个在线工具:
简单来说, B树是在红黑树(一个平衡二叉树)的基础上将一个节点存放多个值, 实现的, 降低了树的高度, 每个节点都存放索引及对应数据指针, 同一层的节点是递增的
而B+树在B树的基础上进行优化, 非叶子节点存放 子节点的开始的索引, 叶子节点存放索引和数据的指针, 且叶子节点之间有双向的指针
如下示意图:
不同的引擎, 主键索引存放的数据也不一样, 比如常见的 MyISAM 和 InnoDB
MyISAM 的B+树叶子节点存放表数据的指针, InnoDB 的B+树叶子节点存放处主键外的数据
其他的:
即多个列组成一个索引, 语法:
如果你对列进行了 （+,-,*,/,!） , 那么都将不会走索引.
OR 引起的索引失效
OR 导致索引是在特定情况下的,并不是所有的 OR 都是使索引失效,如果OR连接的是 同 一个字段,那么索引 不会失效 , 反之索引失效 .
这个我相信大家都明白,模糊搜索如果你前缀也进行模糊搜索,那么不会走索引.
这两种用法,也将使索引失效.另 IN 会走索引,但是当IN的取值范围较大时会导致索引失效,走全表扫描, 见: MySQL中使用IN会不会走索引
不走索引.
走索引.
所以设计表的时候, 建议不可为空, 而是将默认值设置为 "" ( NOT NULL DEFAULT "" )
①.、InnoDB存储引擎
存储格式 : 数据,索引集中存储,存储于同一个表空间文件中.
InnoDB的行锁模式及其加锁方法： InnoDB中有以下两种类型的行锁：共享锁（读锁： 允许事务对一条行数据进行读取）和 互斥锁（写锁： 允许事务对一条行数据进行删除或更新）, 对于update,insert,delete语句,InnoDB会自动给设计的数据集加互斥锁,对于普通的select语句,InnoDB不会加任何锁.
InnoDB行锁的实现方式： InnoDB行锁是通过给索引上的索引项加锁来实现的,如果没有索引,InnoDB将通过隐藏的聚簇索引来对记录加锁.InnoDB这种行锁实现特点意味着：如果不通过索引条件检索数据,那么InnoDB将对表中的所有记录加锁,实际效果跟表锁一样.
（1）在不通过索引条件查询时,InnoDB会锁定表中的所有记录.
优点：
①.、支持事务处理、ACID事务特性；
缺点：
因为它没有保存表的行数,当使用COUNT统计时会扫描全表.
使用场景：
功能：
（1）支持数据压缩存储,但压缩后的表变成了只读表,不可写；如果需要更新数据,则需要先解压后更新.
①高性能读取；
①.、锁级别为表锁,表锁优点是开销小,加锁快；缺点是锁粒度大,发生锁冲动概率较高,容纳并发能力低,这个引擎适合查询为主的业务.
InnoDB和MyISAM一些细节上的差别：
①.．索引概述
利用关键字,就是记录的部分数据（某个字段,某些字段,某个字段的一部分）,建立与记录位置的对应关系,就是索引.索引的关键字一定是排序的.索引本质上是表字段的有序子集,它是提高查询速度最有效的方法.一个没有建立任何索引的表,就相当于一本没有目录的书,在每次查询时就会进行全表扫描,这样会导致查询效率极低、速度也极慢.如果建立索引,那么就好比一本添加的目录,通过目录的指引,迅速翻阅到指定的章节,提升的查询性能,节约了查询资源.
从索引的定义方式和用途中来看：主键索引,唯一索引,普通索引,全文索引.
无论任何类型,都是通过建立关键字与位置的对应关系来实现的.索引是通过关键字找对应的记录的地址.
以上类型的差异：对索引关键字的要求不同.
关键字：记录的部分数据（某个字段,某些字段,某个字段的一部分）.
普通索引,index：对关键字没有要求.
唯一索引,unique index：要求关键字不能重复.同时增加唯一约束.
主键索引,primary key：要求关键字不能重复,也不能为NULL.同时增加主键约束.
PS：这里主键索引和唯一索引的区别在于：主键索引不能为空值,唯一索引允许空值；主键索引在一张表内只能创建一个,唯一索引可以创建多个.主键索引肯定是唯一索引,但唯一索引不一定是主键索引.
如果索引不遵循使用原则,则可能导致索引无效.
（1）列独立
如果需要某个字段上使用索引,则需要在字段参与的表达中,保证字段独立在一侧.否则索引不会用到索引, 例如这条sql就不会用到索引:select * from A where id+1=10;
复合索引：一个索引关联多个字段,仅仅针对左边字段有效果,添加复合索引时,第一个字段很重要,只有包含第一个字段作为查询条件的情况才会使用复合索引(必须用到建索引时选择的第一个字段作为查询条件,其他字段的顺序无关),而且查询条件只能出现and拼接,不能用or,否则则无法使用索引.
必须要保证 OR 两端的条件都存在可以用的索引,该查询才可以使用索引.
即使满足了上面说原则,MySQL也能弃用索引,例如：select * from A where id 1;这里弃用索引的主要原因：查询即使使用索引,会导致出现大量的随机IO,相对于从数据记录的第一条遍历到最后一条的顺序IO开销,还要大.
（1）索引检索：检索数据时使用索引.
建立索引索引时,不能仅仅考虑where检索,同时考虑其他的使用场景.（在所有的where字段上增加索引,就是不合理的）
前缀索引是建立索引关键字一种方案.通常会使用字段的整体作为索引关键字.有时,即使使用字段前部分数据,也可以去识别某些记录.就比如一个班级里,我要找王xx,假如姓王的只有1个人,那么就可以建一个关键字为'王'的前缀索引.语法：Index +index_name+ (+index_field+(N))使用index_name前N个字符建立的索引.
（1） 应尽量避免在 where 子句中使用 != 或 操作符,否则将引擎放弃使用索引而进行全表扫描；
join 的两种算法：BNL 和 NLJ
NLJ（Nested Loop Join）嵌套循环算法；以如下 SQL 为例：
SQL 执行时内部流程是这样的：
① 先从 t1（假设这里 t1 被选为驱动表）中取出一行数据 X；
BNLJ（Block Nested Loop Join）块嵌套循环算法；
① 把 t1 表（假设这里 t1 被选为驱动表）满足条件的数据全部取出放到线程的 join buffer 中；
BNLJ相对于NLJ的优点在于,驱动层可以先将部分数据加载进buffer,这种方法的直接影响就是将大大减少内层循环的次数,提高join的效率.
例如：
如果内层循环有100条记录,外层循环也有100条记录,这样的话,每次外层循环先将10条记录放到buffer中,内层循环的100条记录每条与这个buffer中的10条记录进行匹配,只需要匹配内层循环总记录数次即可结束一次循环（今天这一节,即只需要匹配100次即可结束）,然后将匹配成功的记录连接后放入结果集中,接着,外层循环继续向buffer中放入10条记录,同理进行匹配,并将成功的记录连接后放入结果集.后续循环以此类推,直到循环结束,将结果集发给client为止.
可以发现,若用NLJ,则需要100 * 100次才可结束,BNLJ则需要100 / block_size * 100 = 10 * 100次就可结束,大大减少了循环次数.
JOIN 按照功能大致分为如下三类：
JOIN、STRAIGHT_JOIN、INNER JOIN（内连接,或等值连接）：取得两个表中存在连接匹配关系的记录.
注意：mysql不支持Full join,不过可以通过UNION 关键字来合并 LEFT JOIN 与 RIGHT JOIN来模拟FULL join.
mysql 多表连接查询方式,因为mysql只支持NLJ算法,所以如果是小表驱动大表则效率更高；反之则效率下降；所以呢mysql对内连接或等值连接的方式做了一个优化,会去判断join表的数据行大小,然后取数据行小的表为驱动表.
INNER JOIN、JOIN、WHERE等值连接和STRAIGHT_JOIN都能表示内连接,那平时如何选择呢?一般情况下用INNER JOIN、JOIN或者WHERE等值连接,因为MySQL 会按照"小表驱动大表的策略"进行优化.当出现需要排序时,才考虑用STRAIGHT_JOIN指定某张表为驱动表.
两表JOIN优化
a.当无order by条件时,根据实际情况,使用left/right/inner join即可,根据explain优化 ；
b.当有order by条件时,如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解释语句；
①.）如果第一行的驱动表为a,则效率会非常高,无需优化；
在使用left join（或right join）时,应该清楚的知道以下几点：
(1). on与 where的执行顺序
ON 条件（"A LEFT JOIN B ON 条件表达式"中的ON）用来决定如何从 B 表中检索数据行.如果 B 表中没有任何一行数据匹配 ON 的条件,将会额外生成一行所有列为 NULL 的数据,在匹配阶段 WHERE 子句的条件都不会被使用.仅在匹配阶段完成以后,WHERE 子句条件才会被使用.它将从匹配阶段产生的数据中检索过滤.
所以我们要注意：在使用Left (right) join的时候,一定要在先给出尽可能多的匹配满足条件,减少Where的执行.
即使右表的数据不满足ON后面的条件,也会在结果集拼接一条为NULL的数据行,但WHERE后面的条件不一样,右表不满足WHERE的条件,左表关联的数据也会被过滤掉.
往往性能这玩意儿,更多时候体现在数据量比较大的时候,此时,我们应该避免复杂的子查询.
for update 的作用是在查询的时候为行加上排它锁,当一个事务的操作未完成时候,其他事务可以读取但是不能写入或更新.
它的典型使用场景是 高并发并且对于数据的准确性有很高要求 ,比如金钱、库存等,一般这种操作都是很长一串并且开启事务的,假如现在要对库存进行操作,在刚开始读的时候是1,然后马上另外一个进程将库存更新为0了,但事务还没结束,会一直用1进行后续的逻辑,就会有问题,所以需要用for upate 加锁防止出错.
行锁的具体实现算法有三种：record lock、gap lock以及next-key lock.
只在可重复读或以上隔离级别下的特定操作才会取得 gap lock 或 next-key lock,在 Select、Update 和 Delete 时,除了基于唯一索引的查询之外,其它索引查询时都会获取 gap lock 或 next-key lock,即锁住其扫描的范围.主键索引也属于唯一索引,所以主键索引是不会使用 gap lock 或 next-key lock
for update 仅适用于InnoDB,并且必须开启事务,在begin与commit之间才生效.
select 语句默认不获取任何锁,所以是可以读被其它事务持有排它锁的数据的！
InnoDB 既实现了行锁,也实现了表锁.
当有明确指定的主键/索引时候,是行级锁,否则是表级锁
明确指定主键,并且有此记录,行级锁
无主键/索引,表级锁
主键/索引不明确,表级锁
明确指定主键/索引,若查无此记录,无锁
参考博文：
①.、SQL语句执行流程
MySQL大体上可分为Server层和存储引擎层两部分.
Server层：
连接器：TCP握手后服务器来验证登陆用户身份,A用户创建连接后,管理员对A用户权限修改了也不会影响到已经创建的链接权限,必须重新登陆.
分析器：根据语法规则,判断你输入的这个SQL语句是否满足MySQL语法.
优化器：多种执行策略可实现目标,系统自动选择最优进行执行.
执行器：判断是否有权限,将最终任务提交到存储引擎.
存储引擎层
SQL执行顺序
BinLog
BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志,主从数据库同步用到的都是BinLog文件.BinLog日志文件有三种模式.
STATEMENT 模式
内容：binlog 记录可能引起数据变更的 sql 语句
优势：该模式下,因为没有记录实际的数据,所以日志量很少 IO 都消耗很低,性能是最优的
劣势：但有些操作并不是确定的,比如 uuid() 函数会随机产生唯一标识,当依赖 binlog 回放时,该操作生成的数据与原数据必然是不同的,此时可能造成无法预料的后果.
ROW 模式
内容：在该模式下,binlog 会记录每次操作的源数据与修改后的目标数据,StreamSets就要求该模式.
优势：可以绝对精准的还原,从而保证了数据的安全与可靠,并且复制和数据恢复过程可以是并发进行的
劣势：缺点在于 binlog 体积会非常大,同时,对于修改记录多、字段长度大的操作来说,记录时性能消耗会很严重.阅读的时候也需要特殊指令来进行读取数据.
MIXED 模式
内容：是对上述STATEMENT 跟 ROW 两种模式的混合使用.
细节：对于绝大部分操作,都是使用 STATEMENT 来进行 binlog 没有记录,只有以下操作使用 ROW 来实现：表的存储引擎为 NDB,使用了uuid() 等不确定函数,使用了 insert delay 语句,使用了临时表
主从同步流程：
①.、主节点必须启用二进制日志,记录任何修改了数据库数据的事件.
mysql默认的复制方式是异步的,并且复制的时候是有并行复制能力的.主库把日志发送给从库后不管了,这样会产生一个问题就是假设主库挂了,从库处理失败了,这时候从库升为主库后,日志就丢失了.由此产生两个概念.
全同步复制
半同步复制
半同步复制的逻辑是这样,从库写入日志成功后返回ACK确认给主库,主库收到至少一个从库的确认就认为写操作完成.
还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟,如何避免这个问题?主备切换的时候用可靠性优先原则还是可用性优先原则?如何判断主库Crash了?互为主备的情况下如何避免主备循环复制?被删库跑路了如何正确恢复?( o )... 感觉越来越扯到DBA的活儿上去了.
RedoLog
可以先通过下面demo理解：
饭点记账可以把账单写在账本上也可以写在粉板上.有人赊账或者还账的话,一般有两种做法：
①.、直接把账本翻出来,把这次赊的账加上去或者扣除掉.
生意忙时选后者,因为前者太麻烦了.得在密密麻麻的记录中找到这个人的赊账总额信息,找到之后再拿出算盘计算,最后再将结果写回到账本上.
同样在MySQL中如果每一次的更新操作都需要写进磁盘,然后磁盘也要找到对应的那条记录,然后再更新,整个过程IO成本、查找成本都很高.而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术,它的关键点就是先写日志,再写磁盘.此时账本 = BinLog,粉板 = RedoLog.
①.、 记录更新时,InnoDB引擎就会先把记录写到RedoLog（粉板）里面,并更新内存.同时,InnoDB引擎会在空闲时将这个操作记录更新到磁盘里面.
RedoLog有write pos 跟checkpoint
check point：是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件.
write pos和check point之间的是粉板上还空着的部分,可以用来记录新的操作.如果write pos追上checkpoint,表示粉板满了,这时候不能再执行新的更新,得停下来先擦掉一些记录,把checkpoint推进一下.
有了redo log,InnoDB就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为crash-safe. redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致.提交流程大致如下：
binlog跟redolog区别：
redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的,所有引擎都可以使用.
redo log是循环写的,空间固定会用完；binlog是可以追加写入的.追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志.
UndoLog
UndoLog 一般是逻辑日志,主要分为两种：
insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要,并且在事务提交后可以被立即丢弃
update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要,在快照读时也需要；所以不能随便删除,只有在快速读或事务回滚不涉及该日志时,对应的日志才会被purge线程统一清除
索引的常见模型有哈希表、有序数组和搜索树.
哈希表：一种以KV存储数据的结构,只适合等值查询,不适合范围查询.
有序数组：只适用于静态存储引擎,涉及到插入的时候比较麻烦.可以参考Java中的ArrayList.
搜索树：按照数据结构中的二叉树来存储数据,不过此时是N叉树(B+树).广泛应用在存储引擎层中.
B+树比B树优势在于：
B+ 树非叶子节点存储的只是索引,可以存储的更多.B+树比B树更加矮胖,IO次数更少.
B+ 树叶子节点前后管理,更加方便范围查询.同时结果都在叶子节点,查询效率稳定.
B+树中更有利于对数据扫描,可以避免B树的回溯扫描.
索引的优点：
①.、唯一索引可以保证每一行数据的唯一性
索引的缺点：
①.、创建跟维护都需要耗时
索引设计的原则不应该：
①.、索引不是越多越好.索引太多,维护索引需要时间跟空间.
应该：
①.、重复率小的列建议生成索引.因为重复数据少,索引树查询更有效率,等价基数越大越好.
索引失效的场景
①.、模糊搜索：左模糊或全模糊都会导致索引失效,比如'%a'和'%a%'.但是右模糊是可以利用索引的,比如'a%' .
关于索引的知识点：
主键索引：主键索引的叶子节点存的是整行数据信息.在InnoDB里,主键索引也被称为聚簇索引（clustered index）.主键自增是无法保证完全自增的哦,遇到唯一键冲突、事务回滚等都可能导致不连续.
唯一索引：以唯一列生成的索引,该列不允许有重复值,但允许有空值(NULL)
change buffer：普通索引用在更新过程的加速,更新的字段如果在缓存中,如果是普通索引则直接更新即可.如果是唯一索引需要将所有数据读入内存来确保不违背唯一性,所以尽量用普通索引.
非主键索引：非主键索引的叶子节点内容是主键的值.在InnoDB里,非主键索引也被称为二级索引（secondary index）
回表：先通过数据库索引扫描出数据所在的行,再通过行主键id取出索引中未提供的数据,即基于非主键索引的查询需要多扫描一棵索引树.
覆盖索引：如果一个索引包含（或者说覆盖）所有需要查询的字段的值,我们就称之为覆盖索引.
最左前缀原则：对多个字段同时建立的组合索引(有顺序,ABC,ACB是完全不同的两种联合索引) 以联合索引(a,b,c)为例,建立这样的索引相当于建立了索引a、ab、abc三个索引.另外组合索引实际还是一个索引,并非真的创建了多个索引,只是产生的效果等价于产生多个索引.
索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并.增删数据时需考虑页空间利用率.
自增主键：一般会建立与业务无关的自增主键,不会触发叶子节点分裂.
延迟关联：通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据.
InnoDB存储: * .frm文件是一份定义文件,也就是定义数据库表是一张怎么样的表.*.ibd文件则是该表的索引,数据存储文件,既该表的所有索引树,所有行记录数据都存储在该文件中.
MyISAM存储：* .frm文件是一份定义文件,也就是定义数据库表是一张怎么样的表.* .MYD文件是MyISAM存储引擎表的所有行数据的文件.* .MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件.MyISAM引擎下,表数据和表索引数据是分开存储的.
MyISAM查询：在MyISAM下,主键索引和辅助键索引都属于非聚簇索引.查询不管是走主键索引,还是非主键索引,在叶子结点得到的都是目的数据的地址,还需要通过该地址,才能在数据文件中找到目的数据.
PS：InnoDB支持聚簇索引,MyISAM不支持聚簇索引
ACID的四个特性
原子性（Atomicity）：把多个操作放到一个事务中,保证这些操作要么都成功,要么都不成功
一致性（Consistency）：理解成一串对数据进行操作的程序执行下来,不会对数据产生不好的影响,比如凭空产生,或消失
持久性（Durability）：当某个操作操作完毕了,那么结果就是这样了,并且这个操作会持久化到日志记录中
PS：ACID中C与CAP定理中C的区别
ACID的C着重强调单数据库事务操作时,要保证数据的完整和正确性,数据不会凭空消失跟增加.CAP 理论中的C指的是对一个数据多个备份的读写一致性
事务操作可能会出现的数据问题
①.、脏读(dirty read)：B事务更改数据还未提交,A事务已经看到并且用了.B事务如果回滚,则A事务做错了
在说隔离级别之前,你首先要知道,你隔离得越严实,效率就会越低.所以呢很多时候,我们都要在二者之间寻找一个平衡点.SQL标准的事务隔离级别由低到高如下： 上图从上到下的模式会导致系统的并行性能依次降低,安全性依次提高.
读未提交：别人改数据的事务尚未提交,我在我的事务中也能读到.
读已提交(Oracle默认)：别人改数据的事务已经提交,我在我的事务中才能读到.
可重复读(MySQL默认)：别人改数据的事务已经提交,我在我的事务中也不去读,以此保证重复读一致性.
串行：我的事务尚未提交,别人就别想改数据.
标准跟实现：上面都是关于事务的标准,但是每一种数据库都有不同的实现,比如MySQL InnDB 默认为RR级别,但是不会出现幻读.因为当事务A更新了所有记录的某个字段,此时事务A会获得对这个表的表锁,因为事务A还没有提交,所以事务A获得的锁没有释放,此时事务B在该表插入新记录,会因为无法获得该表的锁,则导致插入操作被阻塞.只有事务A提交了事务后,释放了锁,事务B才能进行接下去的操作.所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读,不可重复读和幻读的.
无论是Java的并发编程还是数据库的并发操作都会涉及到锁,研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想.
悲观锁：
优点：适合在写多读少的并发环境中使用,虽然无法维持非常高的性能,但是在乐观锁无法提更好的性能前提下,可以做到数据的安全性
缺点：加锁会增加系统开销,虽然能保证数据的安全,但数据处理吞吐量低,不适合在读书写少的场合下使用
乐观锁：
优点：在读多写少的并发场景下,可以避免数据库加锁的开销,提高DAO层的响应性能,很多情况下ORM工具都有带有乐观锁的实现,所以这些方法不一定需要我们人为的去实现.
缺点：在写多读少的并发场景下,即在写操作竞争激烈的情况下,会导致CAS多次重试,冲突频率过高,导致开销比悲观锁更高.
实现：数据库层面的乐观锁其实跟CAS思想类似, 通数据版本号或者时间戳也可以实现.
数据库并发场景主要有三种：
读-读：不存在任何问题,也不需要并发控制
读-写：有隔离性问题,可能遇到脏读,幻读,不可重复读
写-写：可能存更新丢失问题,比如第一类更新丢失,第二类更新丢失
两类更新丢失问题：
第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果
为了合理贯彻落实锁的思想,MySQL中引入了杂七杂八的各种锁：
锁分类
MySQL支持三种层级的锁定,分别为
表级锁定
MySQL中锁定粒度最大的一种锁,最常使用的MYISAM与INNODB都支持表级锁定.
页级锁定
是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁,表级锁速度快,但冲突多,行级冲突少,但速度慢.所以取了折衷的页级,一次锁定相邻的一组记录.
行级锁定
Mysql中锁定粒度最细的一种锁,表示只针对当前操作的行进行加锁.行级锁能大大减少数据库操作的冲突.其加锁粒度最小,但加锁的开销也最大行级锁不一定比表级锁要好：锁的粒度越细,代价越高,相比表级锁在表的头部直接加锁,行级锁还要扫描找到对应的行对其上锁,这样的代价其实是比较高的,所以表锁和行锁各有所长.
MyISAM中的锁
虽然MySQL支持表,页,行三级锁定,但MyISAM存储引擎只支持表锁.所以MyISAM的加锁相对比较开销低,但数据操作的并发性能相对就不高.但如果写操作都是尾插入,那还是可以支持一定程度的读写并发
从MyISAM所支持的锁中也可以看出,MyISAM是一个支持读读并发,但不支持通用读写并发,写写并发的数据库引擎,所以它更适合用于读多写少的应用场合,一般工程中也用的较少.
InnoDB中的锁
该模式下支持的锁实在是太多了,具体如下：
共享锁和排他锁 (Shared and Exclusive Locks)
意向锁（Intention Locks）
记录锁（Record Locks）
间隙锁（Gap Locks）
临键锁 （Next-Key Locks）
插入意向锁（Insert Intention Locks）
主键自增锁 (AUTO-INC Locks)
空间索引断言锁（Predicate Locks for Spatial Indexes）
举个栗子,比如行锁里的共享锁跟排它锁：lock in share modle 共享读锁：
为了确保自己查到的数据没有被其他的事务正在修改,也就是说确保查到的数据是最新的数据,并且不允许其他人来修改数据.但是自己不一定能够修改数据,因为有可能其他的事务也对这些数据使用了 in share mode 的方式上了S 锁.如果不及时的commit 或者rollback 也可能会造成大量的事务等待.
for update排它写锁:
为了让自己查到的数据确保是最新数据,并且查到后的数据只允许自己来修改的时候,需要用到for update.相当于一个 update 语句.在业务繁忙的情况下,如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待,从而影响数据库的并发使用效率.
Gap Lock间隙锁：
①.、行锁只能锁住行,如果在记录之间的间隙插入数据就无法解决了,所以呢MySQL引入了间隙锁(Gap Lock).间隙锁是左右开区间.间隙锁之间不会冲突.
间隙锁加锁原则(学完忘那种)：
①.、加锁的基本单位是 NextKeyLock,是前开后闭区间.