MySQL高频面试题，都在这了！，使用Docker部署Spring-Boot项目

本文链接：https://blog.csdn.net/m0_60226911/article/details/136696392

1.什么是事务?

理解什么是事务最经典的就是转账的栗子,相信大家也都了解，这里就不再说一边了.

事务是一系列的操作,他们要符合ACID特性.最常见的理解就是:事务中的操作要么全部成功,要么全部失败.但是只是这样还不够的.

2. ACID是什么?可以详细说一下吗?

A=Atomicity

原子性,就是.上面说的,要么全部成功,要么全部失败.不可能只执行一部分操作.

C=Consistency

系统(数据库)总是从一个-致性的状态转移到另一个一致性的状态,不会存在中间状态.

I=Isolation

隔离性:通常来说:一个事务在完全提交之前,对其他事务是不可见的.注意前面的通常来说加了红色，意味着有例外情况.

D=Durability

持久性,一-旦事务提交,那么就永远是这样子了,哪怕系统崩溃也不会影响到这个事务的结果.

3.同时有多个事务在进行会怎么样呢?

多事务的并发进行一般会造成以下几个问题:

●脏读: A事务读取到了B事务未提交的内容,而B事务后面进行了回滚.

●不可重复读:当设置A事务只能读取B事务已经提交的部分，会造成在A事务内的两次查询,结果竟然不-样,因为在此期间B事务进行了提交操作.

●幻读: A事务读取了一一个范围的内容,而同时B事务在此期间插入了-条数据造成”幻觉".

4.怎么解决这些问题呢?MySQL的事务隔离级别了解吗?

MySQL的四种隔离级别如下:

●未提交读(READ UNCOMMITTED)

这就是.上面所说的例外情况了,这个隔离级别下，其他事务可以看到本事务没有提交的部分修改因此会造成脏读的问题(读取到了其他事务未提交的部分,而之后该事务进行了回滚).

这个级别的性能没有足够大的优势,但是又有很多的问题,因此很少使用.

●已提交读(READ COMMITTED)

其他事务只能读取到本事务已经提交的部分.这个隔离级别有不可重复读的问题,在同-一个事务内的两次读取,拿到的结果竟然不一样,因为另外- -个事务对数据进行了修改.

●REPEATABLE READ(可重复读)

可重复读隔离级别解决了上面不可重复读的问题(看名字也知道),但是仍然有-个新问题,就是幻读,当你读取id> 10的数据行时,对涉及到的所有行加上了读锁,此时例外一个事务新插入了-条id=11的数据,因为是新插入的,所以不会触发上面的锁的排斥,那么进行本事务进行下一次的查询时会发现有一条id=11的数据,而上次的查询操作并没有获取到,再进行插入就会有主键冲突的问题.

●SERIALIZABLE(可串行化)

这是最高的隔离级别,可以解决上面提到的所有问题,因为他强制将所以的操作串行执行,这会导致并发性能极速下降,因此也不是很常用.

5. Innodb使用的是种隔离级别呢?

InnoDB默认使用的是可重复读隔离级 需要zi料+ 绿色徽【vip1024b】

别.

6.对MySQL的锁了解吗?

当数据库有并发事务的时候，可能会产生数据的不一致,这时候需要一些机制来保证访问的次序锁机制就是这样的一一个机制.

就像酒店的房间,如果大家随意进出,就会出现多人抢夺同-个房间的情况,而在房间上装上锁,申请到钥匙的人才可以入住并且将房间锁起来,其他人只有等他使用完毕才可以再次使用.

7. MySQL都有哪些锁呢?像上面那样子进行锁定岂不是有点阻碍并发效率了?

从锁的类别上来讲,有共享锁和排他锁.

共享锁:又叫做读锁.当用户要进行数据的读取时，对数据加上共享锁共享锁可以同时加上多个.

排他锁:又叫做写锁.当用户要进行数据的写入时,对数据加上排他锁排他锁只可以加一-个 ,他和其他的排他锁,共享锁都相斥.

用上面的例子来说就是用户的行为有两种,- -种是来看房，多个用户-起看房是可以接受的.- -种是真正的入住一-晚,在这期间,无论是想入住的还是想看房的都不可以.

锁的粒度取决于具体的存储引擎,InnoDB实现了行级锁,页级锁,表级锁.他们的加锁开销从大大小,并发能力也是从大到小.

表结构设计

1.为什么要尽量设定-个主键?

主键是数据库确保数据行在整张表唯- -性的保障,即使业务上本张表没有主键,也建议添加一一个自增长的ID列作为主键.设定了主键之后,在后续的删改查的时候可能更加快速以及确保操作数据范围安全

2.主键使用自增ID还是UUID?

推荐使用自增ID,不要使用UUID.

因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降.总之,在数据量大- -些的情况下,用自增主键性能会好一-些.

图片来源于《高性能MySQL>:其中默认后缀为使用自增ID,_ uuid为使用UUID为主键的测试测试了插入100w行和300w行的性能

在这里插入图片描述

关于主键是聚簇索引,如果没有主键,InnoDB会选择-个唯- -键来作为聚簇索引,如果没有唯- -键, 会生成一个隐式的主键.

If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.

If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULLcolumns as the primary key and InnoDB uses it as the clustered index.

3.字段为什么要求定义为not null?

MySQL官网这样介绍

NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables,each NULL columntakes one bit extra, rounded up to the nearest byte.

null值会占用更多的字节,且会在程序中造成很多与预期不符的情况.

4.如果要存储用户的密码散列,应该使用什么字段进行存储?

密码散列,盐,用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率.

存储引擎相关

1. MySQL支持哪些存储引擎?

MySQL支持多种存储引擎,比如InnoDB,MyISAM,Memory,Archive等等.在大多数的情况下,直接选择使用InnoDB引擎都是最合适的,InnoDB也是MySQL的默认存储引擎.