2024年java面试--mysql(2)
系列文章目录
- 2024年java面试（一）–spring篇
- 2024年java面试（二）–spring篇
- 2024年java面试（三）–spring篇
- 2024年java面试（四）–spring篇
- 2024年java面试–集合篇
- 2024年java面试–redis(1)
- 2024年java面试–redis(2)
文章目录
- 系列文章目录
- MVCC
- 聚簇索引和非聚簇索引 （聚集索引和二级索引）
- 哈希索引
- 为什么用B+树索引而不用哈希索引？
- 为什么InnoDB推荐用整型自增主键，而不是uuid？
- 索引失效场景有哪些
- 事务4大特性
- 事务隔离级别
- 默认隔离级别-RR
- RR和RC使用场景
- 并发事务带来哪些问题？
- 应该如何解决？
- InnoDB 如何开启手动提交事务？
MVCC
全称Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
三个隐式字段：
undo log日志：
回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。
readView：
ReadView（读视图）是快照读SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。
ReadView中包含了四个核心字段：
不同的隔离级别，生成ReadView的时机不同:
READ COMMITTED:在事务中每一次执行快照读时生成Readview。
REPEATABLE READ:仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView
聚簇索引和非聚簇索引 （聚集索引和二级索引）
聚簇索引： 将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据（主键索引）
非聚簇索引： 将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置（辅助索引）
聚簇索引的叶子节点就是数据节点，而非聚簇索引的叶子节点仍然是索引节点，只不过有指向对应数据块的指针。
聚集索引选取规则：
- 如果存在主键，主键索引就是聚集索引。
- 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
- 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。
哈希索引
哈希索引用索引列的值计算该值的hashCode，然后在hashCode相应的位置存执该值所在行数据的物理位置，因为使用散列算法，因此访问速度非常快，但是一个值只能对应一个hashCode，而且是散列的分布方式，因此哈希索引不支持范围查找和排序的功能
为什么用B+树索引而不用哈希索引？
哈希索引，建立的是索引值的哈希值和物理磁盘地址之间的映射
（1）哈希冲突多的时候，性能也不一定就比B+树好
（2）哈希索引不支持范围查询，只能点对点查询，哈希运算前的索引值和哈希运算后的哈希值顺序并不一定一样
（3）哈希索引不能利用部分索引键查询，哈希索引在计算哈希值的时候是组合索引键合并后再一起计算哈希值，而不是单独计算哈希值，所以通过组合索引的前面一个或几个索引键进行查询的时候，哈希索引也无法被利用
为什么InnoDB推荐用整型自增主键，而不是uuid？
（1）uuid占用空间更多。uuid是随机字符串，占用空间更多，整型更少。
（2）uuid排序不如整型容易。uuid是字符串，而节点中的索引值需要排序，显然整型排序更容易。
（3）整型自增插入时可避免节点频繁分裂。插入数据时，自增主键对B+树结构影响很小，由于是递增，往后加就行，而uuid是随机的，可能插到中间，如果前面节点已经满了，会导致节点分裂（页分裂）、树结构调整等大量耗费性能的操作。
索引失效场景有哪些
（1）当联合索引不满足最左匹配原则，相当于创建多列索引，没有最左优先，那么联合查询也就失效（如果使用了<或者>右边的索引将会失效改成>=或者<=就正常）
（2）在查询时，使用错误的模糊查询（如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。）
（3）当列使用运算操作和函数时，索引就失效了
（4）列使用了类型转换，也会导致索引失效（例如字符串类型不加引号进行查询）
（5）使用了is not null，那么索引就会失效（不固定取决于当前数据库表中的数据分布如果表中都有数据或者极少数没有数据使用is null走索引 使用is not null不走索引因为根据表中数据的量来决定如果量多就走全局扫描）
（6）or连接：如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
事务4大特性
事务4大特性： 原子性、一致性、隔离性、持久性
原⼦性： 事务是最⼩的执⾏单位，不允许分割。事务的原⼦性确保动作要么全部完成，要么全不执行
一致性： 执⾏事务前后，数据保持⼀致，多个事务对同⼀个数据读取的结果是相同的；
隔离性： 并发访问数据库时，⼀个⽤户的事务不被其他事务所⼲扰，各并发事务之间数据库是独⽴的；
持久性： ⼀个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发⽣故障也不应该对其有任何影响。
事务靠什么保证：
-
原子性：由undolog日志保证，他记录了需要回滚的日志信息，回滚时撤销已执行的sql
-
一致性：由其他三大特性共同保证，是事务的目的
-
隔离性：由MVCC保证
-
持久性：由redolog日志和内存保证，mysql修改数据时内存和redolog会记录操作，宕机时可恢复
事务隔离级别
读未提交： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
读已提交： 允许读取并发事务已经提交的数据，可以阻⽌脏读，但是幻读或不可重复读仍有可能发⽣。
可重复读： 同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改，可以阻⽌脏读和不可重复读，会有幻读。
串行化： 最⾼的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执⾏，这样事务之间就完全不可能产⽣⼲扰。
| 隔离级别 | 并发问题 |
|---|---|
| 读未提交 | 可能会导致脏读、幻读或不可重复读 |
| 读已提交 | 可能会导致幻读或不可重复读 |
| 可重复读 | 可能会导致幻读 |
| 可串行化 | 不会产⽣⼲扰 |
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读取未提交 | √ | √ | √ |
| 读取已提交 | × | √ | √ |
| 可重复读 | × | × | √ |
| 可串行化 | × | × | × |
1、脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
例如： 张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。 与此同时， 事务B正在读取张三的工资，读取到张三的工资为8000。 随后， 事务A发生异常，而回滚了事务。张三的工资又回滚为5000。 最后， 事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。
2、不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
例如： 在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。 与此同时， 事务B把张三的工资改为8000，并提交了事务。 随后， 在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。
3、幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
例如： 两个cmd窗口开启事务 在第一个窗口中进行查询id=3，没有数据，此时在第二个窗口进行插入id=3，在第一个窗口中也进行插入id=3的操作显示已经存在，但是再查询id=3也还是没有数据
默认隔离级别-RR
默认隔离级别： 可重复读；
同⼀字段的多次读取结果都是⼀致的，除⾮数据是被本身事务⾃⼰所修改；
可重复读是有可能出现幻读的，如果要保证绝对的安全只能把隔离级别设置成SERIALIZABLE；这样所有事务都只能顺序执行，自然不会因为并发有什么影响了，但是性能会下降许多。
第二种方式，使用MVCC解决快照读幻读问题（如简单select），读取的不是最新的数据。维护一个字段作为version，这样可以控制到每次只能有一个人更新一个版本。
select id from table_xx where id = ? and version = V
update id from table_xx where id = ? and version = V+1
第三种方式，如果需要读最新的数据，可以通过GapLock+Next-KeyLock可以解决当前读幻读问题，
select id from table_xx where id > 100 for update;
select id from table_xx where id > 100 lock in share mode;
RR和RC使用场景
事务隔离级别RC(read commit)和RR（repeatable read）两种事务隔离级别基于多版本并发控制MVCC(multi-version concurrency control）来实现。
| RC | RR | |
|---|---|---|
| 实现 | 多条查询语句会创建多个不同的ReadView | 仅需要一个版本的ReadView |
| 粒度 | 语句级读一致性 | 事务级读一致性 |
| 准确性 | 每次语句执行时间点的数据 | 第一条语句执行时间点的数据 |
并发事务带来哪些问题？
脏读： 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是没有被提交的，那么事务读到的这个数据是“脏数据”
丢失修改： 一个事务修改一个数据的时，另外一个事务也读取到这个数据，当第一个事务对他进行修改后，第二个事务也进行了修改，这样第一个事务的修改结果就丢失了，因此被称为丢失修改
不可重复读: 指一个事务内多次读同一个事务，在这个事务还没有结束的时候，另外一个事务也访问该数据。那么第一事务的两次读取数据之间，由于第二个事务的修改导致一个事务内两次读到的数据是不太一样的情况，因此称为不可重复读。
幻读: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻卷一样，所以称为幻读。
应该如何解决？
并发事务可能造成：脏读、不可重复读和幻读等问题 ，这些问题其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决，解决方案如下：
加锁：在读取数据前，对其加锁，阻止其他事务对数据进行修改。例如，读的时候加共享锁，此时其他事物无法修改相应的数据，写的时候加排他锁，禁止其他事物读写操作，但是这种做法性能较差。基于性能考虑MySQL提供了数据多版本并发控制(MVCC)，也称为多版本数据库：不用加任何锁， 通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot)， 并用这个快照来提供一定级别 (语句级或事务级) 的一致性读取，从用户的角度来看，好象是数据库可以提供同一数据的多个版本。
不可重复读和幻读的区别：
不可重复读的重点是修改比如多次读取一条记录发现其中某列的值被修改，幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。
InnoDB 如何开启手动提交事务？
InnoDB 默认是自动提交事务的，每一次 SQL 操作(非 select 操作)都会自动提交一个事务，如果要手动开启事务需要设置set autocommit=0禁止自动提交事务，相当于开启手动提交事务。
在 InnoDB 中设置了 autocommit=0，添加一条信息之后没有手动执行提交操作，请问这条信息可以被查到吗？
autocommit=0 表示禁止自动事务提交，在添加操作之后没有进行手动提交，默认情况下其他连接客户端是查询不到此条新增数据的。