数据库面试复习问题
数据库三大范式
第一范式（1NF）：无重复的列，每个属性都是不可再分割的原子项
第二范式（2NF）：属性完全依赖于主键（消除部分子函数依赖）
第三范式（3NF）：属性不依赖于其他非主属性（消除传递依赖）。非主属性都是与主键直接相关，直接依赖的，不是间接相关间接依赖。
数据库的架构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6b5icPYI-1676005640449)(en-resource://database/837:0)]
MySQL可以分为应用层,逻辑层,数据库引擎层,物理层。
应用层：负责和客户端，响应客户端请求，建立连接，返回数据。满足各种语言的API
逻辑层：系统管理和控制工具（数据库安全，数据库备份，集群调节）SQL接口，解析器，查询优化器，连接池与缓存。
数据库引擎层：负责数据的读写与底层文件进行交互，有常见的MyISAM,InnoDB等等。
物理层：负责文件存储，日志等等。
MyISAM,InnoDB的区别
二、MyISAM和InnoDB特点
InnoDB是事务型数据库的首选引擎，是目前MYSQL的默认事务型引擎，是目前最重要、使用最广泛的存储引擎。支持事务安全表（ACID），支持行锁定和外键。
MyISAM是MySQL 的引擎之一，不支持数据库事务，也不支持行级锁和外键。
如何选择InnoDB和MyISAM：
1.InnoDB：如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交和回滚。
2.MyISAM：读取数据快，空间和内存使用比较低。如果表主要是用于读取记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比较低，也可以使用。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BOocNieO-1676005640451)(en-resource://database/634:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GbGGz7P7-1676005640451)(en-resource://database/639:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q7vYBnnm-1676005640451)(en-resource://database/641:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zBRZa6HU-1676005640452)(en-resource://database/643:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LulePU0C-1676005640452)(en-resource://database/645:1)]
锁的分类如何手动给select语句加共享锁？加排斥锁呢？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0HxiF3Db-1676005640452)(en-resource://database/628:1)]
按锁粒度分类
全局锁：锁的是整个database，由MySQL的SQL Layer层实现，一般情况下不用。
表级锁：锁的是整个table，大多由MySQL的SQL Layer层实现，部分存储引擎也会实现表级锁，如InnoDB实现的意向锁就属于表级锁。
行级锁：锁的是某行数据，也可能锁定行之间的间隙。由存储引擎实现，如InnoDB。
页面锁：锁定粒度介于行级锁与表级锁之间，会出现死锁。各项性能介于表级锁、行级锁之间。使用页面锁的主要存储引擎是BerkeleyDB。
按锁功能分类
共享读锁：共享读锁不会阻塞其他用户对同一张表对读请求，但会阻塞对同一张表对写请求。换言之，当一个SESSION获取到共享读锁后，并不妨碍其他SESSION读取锁定数据，然后却会阻止其他SESSION修改锁定数据，直到锁被释放。
排他写锁：排他写锁会同时阻塞其他用户对同一张表的读、写请求。换言之，当一个SESSION获取到排他写锁后，其他SESSION就不可以修改被锁定当数据，直到锁被释放。
按锁的实现方式分类
悲观锁：认为事务之间数据竞争几率是极低的，直到提交事务之前，才回去锁定。
乐观锁：先取锁再访问，为数据处理的安全提供了保证。
加共享锁
select * from table where id = ? lock in share mode 在最后加lock in share mode
加排它锁
select * from table where id = ? for update 在最后加for update
update,insert,delete语句会自动加排它锁
乐观锁如何保证一致性？
乐观锁保持一致性主要通过两个方法。
通过数据属性中，增加版本号属性，进行比较，比较目前操作数据是否是最新版本。
CAS（compare and swap）即在对数据修改过程中，采用CAS算法，保证在并发下的一致性。
索引建立 索引的规则 索引的分类？
索引的分类
数据结构的角度： B-Tree索引 哈希索引 R-Tree索引 全文索引
物理存储角度：主键索引（聚簇索引）：叶子节点存的是整行的数据 非主键索引（二级索引）：叶子节点存的主键的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o5KT6jHB-1676005640453)(en-resource://database/630:1)]
1、普通索引：
添加普通的索引不会对原来的列产生任何影响，该索引只用来提高查询效率（该列是否非空，是否唯一由列本身的约束条件约束）。
2、唯一索引：
添加唯一索引的列不允许出现重复值，否则报错，但允许有空值（一个表可以有多个唯一索引）。
3、主键索引：
一种添加了非空限制的特殊唯一索引，因为数据存储在文件中只能按一种顺序存储，所以一张表中只允许有一个主键索引。
4、单列索引：
可以是前面三种索引，只要保证该索引对应的是单一列即可，一个表中可以有多个单列索引。
5、联合索引：
由表中的多个列共同构成，遵循最左前缀原则。比如建立联合索引（dept_id，name,score）只有使用到dept_id字段才可能使用name字段、score字段。 下面举个例子： 在某员工表中，建立了（dept_id，name,score）的联合索引。 目标：需要查找dept_id=1，name=a的员工。 只有使用了索引的dept_id字段，才能找到所有的dept_id=1的员工，只有在这基础上再使用name字段才能正确找到dept_id=1，name=a的员工；如果一上来就找name=a的员工，使用的就不是这个联合索引了（可能是name字段的单列索引）。 下面给出一种使用联合索引所有字段的情况：查找dept_id=1，name=b，score=3的员工。 先通过dept_id字段找到所有dept_id=1的员工，在此基础上，再通过name字段找到dept_id=1，name=b的所有员工，在此基础上，再通过score字段找到目标。（在这个过程中，只有左边的索引字段被用到了，右边的索引字段才可能被用到）
主键索引和唯一索引的区别：有了主键，一定有了唯一索引。主键不能为空但是唯一索引可以为空
二、索引的创建原则。
1、字段的数值有唯一性限制。
索引本身可以起到约束的作用，若表中的某一列是需要唯一约束的，可以直接给它建立唯一索引或者主键索引。这样不仅可以达到约束的目的，还可以通过该索引更快速地确定某条记录。
2、频繁作为WHERE查询条件的字段。
索引的作用就是在一定程度上提高查询效率的，当WHERE语句频繁使用某字段的时候，说明要以该列为标准对表数据进行处理，为了提高效率，我们应该为其创建索引，哪怕是普通索引，所能提升的效率也是非常显著的。
3、经常使用GROUP BY和ORDER BY的列。
根据待排序字段的数量来确定建立单列索引或者联合索引。
4、 根据待排序字段的数量来确定建立单列索引或者联合索引。
索引加快了WHERE的筛选速率，若UPDATE/DELETE的字段是非索引字段的话，效率提升得更为明显，因为非索引字段的更新或删除不涉及到索引的维护。
5、DISTINCT字段。
索引会将数据按一定顺序排列，相同的数据都是紧挨着的，这时候再去重，效率当然高。
7、使用类型小的列建立索引。
类型小指的是数据范围小，数据范围小有两个好处：一、查询时，比较操作快；二、占用的存储空间少。
8、使用字符串的前缀创建索引。
比如某字段类型为name VARCHAR(255)，那我们可以选择name(10)建立索引。这样既节约空间，又节省字符串的比较时间。
9、区分度高（散列性高）的列适合做索引。
其实就是选低重复、少重复的列，比如gender列就不适用建立索引（不是男就是女）
10、使用最频繁的列放到联合索引的最左边。
联合索引遵循最左前缀原则。
11、在多字段都需要建立索引的情况下，联合索引优于单列索引。
三、为什么要限制索引的数目。
索引并不是越多越好的！！！
索引需占用
磁盘空间，索引越多，需要的磁盘空间就越大。
索引会影响INSERT、UPDATE、DELETE等语句的性能，而且在数据修改的同时，索引也需要进行维护，从而产生一定的负担。
优化器在选择如何优化查询的时候会对比各个索引，从中挑选一个最优的方案，索引过多，会加剧优化器的工作时间，从而降低查询性能。
何时索引会失效？
复合索引不满足最左匹配原则
查询条件有or
where 查询语句对索引列有数学运算或函数
聚集索引、非聚集索引、覆盖索引回表了解吗？
从非聚集索引上找到对应的主键值然后到聚集索引上查找对应记录的过程为回表
聚集索引和非聚集
索引在 MySQL 数据库中 InnoDB 存储引擎，B+ 树可分为聚集索引和非聚集索引。聚集索引也叫聚簇索引，非聚集索引也叫辅助索引或者二级索引。
建表的时候都会创建一个聚集索引，每张表都有唯一的聚集索引：如果主键被定义了，那么这个主键就是作为聚集索引如果没有主键被定义，那么该表的第一个唯一非空索引作为聚集索引如果没有主键也没有唯一索引，InnoDB 内部会生成一个隐藏的主键作为聚集索引，这个隐藏的主键是一个 6 个字节的列，该类的值会随着数据的插入自增。在创建表添加的索引都是非聚集索引，非聚集索引就是一个为了找到聚集索引的二级索引，通过二级索引索引找到主键，再查找数据。
聚集索引: 指索引项的排序方式和表中数据记录排序方式一致的索引
其实就是一颗B+树，也是一个聚集索引，即数据和索引在一块。叶子节点保存所有的列值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-93tjFqAA-1676005640454)(en-resource://database/632:1)]
非聚集索引
什么时候不适合建立索引
数量较少
频繁的插入删除操作
区分度不大（男女）
where、group by、order by等后面没有使用到的字段，不需要建立索引
已经有冗余的索引的情况（比如已经有a,b的联合索引，不需要再单独建立a索引）
索引下推
可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
Hash索引 BTree索引 B+Tree索引
Hash索引
哈希索引对于每一行数据计算一个哈希码，并将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。
只有 Memory 引擎显式支持哈希索引。受哈希码影响性能不稳定Hash索引不支持范围查询，无法用于排序，也不支持部分索引列匹配查找。
InnoDB对于频繁使用的某些索引值，会在内存中基于 B-Tree 索引之上再创键一个哈希索引，这也被称为自适应Hash索引。
B-Tree
B-Tree 是一种自平衡的树。每个非叶子节点至多有两个子节点。每个节点都存储关键字值。其左子节点的关键字值小于该节点关键字值，且右子节点的关键字值大于或等于该节点关键字值。
B+树
B+树也是是一种自平衡的树。其基本定义与B树相同，不同点在于数据只出现在叶子节点，所有叶子节点增加了一个链指针，方便进行范围查询。
1）B+树的磁盘读写代价更低，节点没有存储数据
因为B+树内部结点没有指向关键字具体信息的指针，内部结点相对B树小
2）B+树的查询更加稳定
因为非终端结点并不是指向文件内容的结点，仅仅是作为叶子结点的关键字索引，因此所有的关键字查询都会走一条从根节点到叶子结点的路径。即s所有关键字查询的长度是一样的，查询效率稳定。
3）更适用于范围查找
explain详解
使用explain分析你SQL执行计划SQL很灵活，一个需求可以很多实现，那哪个最优呢？SQL提供了explain关键字，它可以分析你的SQL执行计划，看它是否最佳。Explain主要看SQL是否使用了索引。
explain关键字用于分析sql语句的执行情况，可以通过他进行sql语句的性能分析。
type：表示连接类型，从好到差的类型排序为
system：系统表，数据已经加载到内存里。
const：常量连接，通过索引一次就找到。
eq_ref：唯一性索引扫描，返回所有匹配某个单独值的行。
ref：非主键非唯一索引等值扫描，const或eq_ref改为普通非唯一索引。
range：范围扫描，在索引上扫码特定范围内的值。
index：索引树扫描，扫描索引上的全部数据。
all：全表扫描。
key：显示MySQL实际决定使用的键。
key_len：显示MySQL决定使用的键长度，长度越短越好
Extra：额外信息
Using filesort：MySQL使用外部的索引排序，很慢需要优化。
Using temporary：使用了临时表保存中间结果，很慢需要优化。
Using index：使用了覆盖索引。
Using where：使用了where。
MYsql日志，事务
MySQL中存在着以下几种日志：重写日志（redo log）、回滚日志（undo log）、二进制日志（bin log）、错误日志（error log）、慢查询日志（slow query log）、一般查询日志（general log）。
redo log: 存储引擎级别的log（InnoDB有，MyISAM没有），该log关注于事务的恢复.在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。
undo log：是存储引擎级别的log（InnoDB有，MyISAM没有）保证数据的原子性，该log保存了事务发生之前的数据的一个版本，可以用于回滚，是MVCC的重要实现方法之一。
bin log：数据库级别的log，关注恢复数据库的数据。
事务：
事务内的语句要么全部执行成功，要么全部执行失败。
原子性
一致性
隔离性
持久性
利用undo log保障原子性。该log保存了事务发生之前的数据的一个版本，可以用于回滚，从而保证事务原子性。利用redo log保证事务的持久性，该log关注于事务的恢复.在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。
利用undo log+redo log保障一致性。事务中的执行需要redo log，如果执行失败，需要undo log 回滚。
redo log与binlog的区别？
redo log是InnoDB引擎特有的，只记录该引擎中表的修改记录。binlog是MySQL的Server层实现的，会记录所有引擎对数据库的修改。
redo log是物理日志，记录的是在具体某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑。
redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
WAL技术是什么？
WAL的全称是Write-Ahead Logging预写日志，它的关键点就是先写日志，再写磁盘。事务在提交写入磁盘前，会先写到redo log里面去。如果直接写入磁盘涉及磁盘的随机I/O访问，涉及磁盘随机I/O访问是非常消耗时间的一个过程，相比之下先写入redo log，后面再找合适的时机批量刷盘能提升性能。
MySQL是如何保证主备一致的？
MySQL通过binlog（二进制日志）实现主备一致。binlog记录了所有修改了数据库或可能修改数据库的语句，而不会记录select、show这种不会修改数据库的语句。在备份的过程中，主库A会有一个专门的线程将主库A的binlog发送给 备库B进行备份。
其中binlog有三种记录格式：
statement:记录对数据库进行修改的语句本身，有可能会记录一些额外的相关信息。优点是binlog日志量少，IO压力小，性能较高。缺点是由于记录的信息相对较少，在不同库执行时由于上下文的环境不同可能导致主备不一致。
row:记录对数据库做出修改的语句所影响到的数据行以及对这些行的修改。比如当修改涉及多行数据，会把涉及的每行数据都记录到binlog。优点是能够完全的还原或者复制日志被记录时的操作。缺点是日志量占用空间较大，IO压力大，性能消耗较大。
mixed:混合使用上述两种模式，一般的语句使用statment方式进行保存，如果遇到一些特殊的函数，则使用row模式进行记录。MySQL自己会判断这条SQL语句是否可能引起主备不一致，如果有可能，就用row格式， 否则就用statement格式。但是在生产环境中，一般会使用row模式。
MySQL的事务数据库隔离级别，哪些导致脏读，哪些导致幻读？解决办法是啥？
序列化（SERIALIZABLE）
当隔离级别为序列化时，用户之间通过一个接着一个的执行当前事务，不能并发执行。这种隔离级别提供了事务之间最大限度的隔离
可重复读（REPEATABLE READ）
这是 MySQL 数据库中的默认事务隔离级别。可重复读是指在同一个事务内，多次读取同一个数据，在可重复读的这一级别上，事务不会被看成一个序列。不过，当前正在执行事务的变化仍然不能被外部看到，也就是说，如果用户在当前事务对数据进行了更改，然后执行 SELECT 语句（显然此时查询的是更改之后的数据），同时在另一个事务中执行了同一条 SELECT 语句多次，结果总是与更改之前的数据是相同的。因为正在执行的事务所产生的数据变化不能被外部看到。
提交读（READ COMMITTED）
READ COMMITTED 隔离级别的安全性要比 REPEATABLE READ 隔离级别的安全性要差。READ COMMITTED 隔离级别的事务可以看到其他事务对数据的修改，也就是说，在事务处理期间，如果其他事务修改了相应的表，那么同一个事务的多个 SELECT 语句可能返回不同的结果。
未提交读（READ UNCOMMITTED）
READ UNCOMMITTED 提供了事务之间最小限度的隔离。
该事务隔离界别除了容易产生幻读和不能重复读之后，处于该级别的事务还可以读到其他事务还没有提交的数据。如果这个事务使用其他事务不提交的变化作为计算基础，然后那些未提交的变化被它们的父事务撤销，这就导致了大量的数据变化了。
脏读 ：一个事务读取到另一个事务还没有提交的数据
不可重复读 ：在一个事务中多次读取同一个数据时，结果出现不一致
幻读 ：在一个事务中，使用相同的 SQL 两次读取，第二次读取到其他事务新插入的行
为什么Innodb要这样设计？
答：假设事务A要update一行记录，在事务A刚开始时，事务B已经delete这条记录并且提交事务了，如果update使用的是快照读，那么事务A就不知道这条记录已被删除了，会继续对这条已被删除的记录进行修改，进而产生冲突，所以进行update的时候必须要获取最新的数据，即使用当前读。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4yAmT4eN-1676005640454)(en-resource://database/626:1)]
MVCC
MVCC为多版本并发控制，即同一条记录在系统中存在多个版本。其存在目的是在保证数据一致性的前提下提供一种高并发的访问性能。对数据读写在不加读写锁的情况下实现互不干扰,从而实现数据库的隔离性,在事务隔离级别为读提交和可重复读中使用到。
引擎主从复制
(1) 主从分工其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。
(2) 基本过程
1)、Mysql的主从同步就是当master（主库）发生数据变化的时候，会实时同步到slave（从库）。
2)、主从复制可以水平扩展数据库的负载能力，容错，高可用，数据备份。3)、不管是delete、update、insert，还是创建函数、存储过程，都是在master上，当master有操作的时候，slave会快速的接受到这些操作，从而做同步。
(3) 用途和条件
1)、mysql主从复制用途
●实时灾备，用于故障切换
●读写分离，提供查询服务
●备份，避免影响业务
2)、主从部署必要条件：
●主库开启binlog日志（设置log-bin参数）
●主从server-id不同
●从库服务器能连通主库
SQL优化方法
核心就是避免全表扫描，多走索引。
列举常用的一些优化方法：
尽量对利用字段较多的建立索引，即在 where 及 order by 涉及的列上建立索引。
尽量避免在 where 子句中使用 or ，null值判断，in 和对字段进行表达式操作
建立索引时需要多考虑最左匹配原则
where、having、group by、order by出现在同一个语句中的执行顺序是什么？having和where除了执行顺序还有什么的区别？
Where, Group By, Having, Order by。
1.having只能用在group by之后，对分组后的结果进行筛选(即使用having的前提条件是分组)。
2.where肯定在group by 之前，即也在having之前。
3.where后的条件表达式里不允许使用聚合函数，而having可以。
4.having后只能跟group by后边字段条件 或者 非group by字段的聚合函数条件（按组查询）
having和where除了执行顺序还有什么的区别？
1.having只能用在group by之后，对分组后的结果进行筛选(即使用having的前提条件是分组)。
4.having后只能跟group by后边字段条件 或者 非group by字段的聚合函数条件（按组查询）
3.where后的条件表达式里不允许使用聚合函数，而having可以。
drop、delete和truncate的区别(2)如果不考虑删除条件，delete删表数据和truncate表的区别？
数据恢复方面：delete 可以恢复删除的数据，而 truncate 和 drop 不能恢复删除的数据。
执行速度方面：drop > truncate > delete。
删除数据方面：drop 是删除整张表，包含行数据和字段、索引等数据，而 truncate 和 drop 只删除了行数据。
添加条件方面：delete 可以使用 where 表达式添加查询条件，而 truncate 和 drop 不能添加 where 查询条件。
重置自增列方面：在 InnoDB 引擎中，truncate 可以重置自增列，而 delete 不能重置自增列
delete是数据操纵语言（DML），其按行删除，支持where语句，执行操作采用行锁，执行操作时会将该操作记录在redo和undo中，因此支持回滚。truncate是数据定义语言（DDL），其操作隐式提交，不支持回滚，不支持where，删除时采用表级锁进行删除。
SQL语句的执行过程数据库基础：DDL,DML,DCL,TCL是啥
1、数据定义语言DDL：
DDL语言操作的对象是数据库中的对象而非对象所包含的数据。
主要的命令有CREATE、ALTER、DROP等
2、数据操作语言DMLDML(Data Manipulation Language)：用于添加/删除/修改/查询/合并数据库中数据，比如SELECT、UPDATE、INSERT、DELETE、MERGE操作，是用来对数据库里的表数据进行操作的语言。
3、数据控制语言DCL(Data Control Language)：是用来设置或更改数据库用户或角色权限的语句,包括(grant,deny,revoke等)。
4、事务控制语言(TCL)TCL(Transaction Control Language)：用来对事务进行管理。COMMIT
非关系型数据库和关系型数据库区别
关系型数据库采用了关系模型（可以简单理解为二维表格类型）组织数据，一般可以遵守事务的ACID（原子等）特性 不是由关系模型进行存储的均可视作非关系型数据库，比如以键值对的redis，图数据库等。
1）灵活 数据字段类型是否灵活
2）读写快慢
3）数据关系 是否连接查询支持
4）扩展性
非关系型数据库有Mongdb,Redis,Hbase,关系型数据库有Mysql,Oracle
- 关系型数据库支持多个表之间连接查询（join）,非关系型数据库不支持连接查询
- 关系型强调数据之间的强关联型，并支持事物来确保数据的增删改查的强一致性，而非关系型数据库对数据的事物则支持的不是很好
- 关系型数据库不灵活，是一种二维的数据结构，而且对一行的数据格式类型要求很高，非关系型数据库数据格式则更灵活，数据字段类型也很灵活
- 非关系型数据库比关系型数据库更容易扩展
- 非关系型数据库对大量的并发读写支持的更好，性能更高，而关系型由于IO瓶颈，高并发读写速度慢，支持不好
- 对于数据量很大，而且数据之间无规律，为了能更好的利用这些数据，就可以用非关系数据库
- 非关系型数据库有Mongdb,Redis,Hbase,关系型数据库有Mysql,Oracle
- redis是内存级数据库，所有数据操作都在内存中进行，数据持久化通过RDB和AOF方式
- Mysql所有的索引和数据都放在硬盘中，所以对数据的操作会有大量的IO耗时，IO是导致读写慢的主要原因
- Mongdb介于二者之间，mongodb的所有数据实际上是存放在硬盘的，所有要操作的数据通过mmap的方式映射到内存某个区域内
11.传统关系型数据库在数据库高并发读写，对海量的数据存储，对数据库的高可扩展性应用场景性能不好
12.mongdb更灵活，适用于需求变更，模型无法确定，要进行扩展等场景，mongdb每条数据都可以灵活增加字段
mysql为什么要用自增id作为主键
直接原因是其存储机制。MySQL采用数据页进行数据存储。 如果采用自增主键，在原先数据页写满的情况下，MySQL对于新数据，直接开辟新页进行写操作。 如果不采用自增主键，为保障索引有序，新数据需插入到合适位置上，由此针对页数据满的情况下，MySQL需要申请新页，并将一部分之前的页数据挪到新页上，保证按索引有序存储，相对自增主键IO开销更大。
分库分表怎么做
对于分库，即将一个数据库拆分为多个库。 可以通过水平拆分，或者垂直拆分的方式，将表进行拆分。 一般可以采用中间件Sharding-JDBC进行分库分表。
MySQL中char和varchar有什么区别？
CHAR的长度是不可变的，而VARCHAR的长度是可变的。 因此CHAR效率高，VARCHAR效率偏低。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kAdSYAfp-1676005640455)(en-resource://database/619:1)]
几个join的区别
1.数据库join的类型主要分为left join、right join、inner join
2.left join 表示左边的表为主表，右边连接的表可以为NULL
如：
select a.id,a.name,b.name,b.city from user a left join liveregion b on a.cityId = b.id;
此处查询就可能出现a表的cityId为NULL时也能b表数据又为NULL的情况,即代表a表数据可以出现NULL
3.right join 表示右边的表为主表，左边连接的表可以为NULL
4.inner join 内连接 表示两个表均相关联的信息。
简述分布式id生成方法
snowflake算法：雪花算法 利用时间戳，机器id，当前数据库自增id进行拼接，生成的新的分布式id。
怎么查出一个表中的重复数据？
select * from people
where peopleId in (select peopleId from people group by peopleId having count
(peopleId) > 1)
外键主键可以是字符串吗(可以)，和整型啥区别
数据库的底层查询是B+树
1，主键id最好是int类型（整型）并且自增，这样再根据主键（索引）查询某一条数据时就会大大提高数据库查询速度，如果是uuid这种字符串和int整型类的主键去对比查询会很慢。
2，节约磁盘空间，因为用uuid一般都是32个字符，而int最大才11位,当然我们也不会让单个表的数据超过千万
union 和 union all 区别
区别1：取结果的交集1、union: 对两个结果集进行并集操作, 不包括重复行,相当于distinct, 同时进行默认规则的排序
;2、union all: 对两个结果集进行并集操作, 包括重复行, 即所有的结果全部显示, 不管是不是重复;
二、区别2：获取结果后的操作1、union: 会对获取的结果进行排序操作2、union all: 不会对获取的结果进行排序操作
union all只是合并查询结果，并不会进行去重和排序操作，在没有去重的前提下，使用union all的执行效率要比union高
LSM 树
算法的关注重心是 “如何在频繁的数据改动下保持系统读取速度的稳定性”，算法的核心在于尽量保证数据是顺序存储到磁盘上的，并且会有频繁地对数据进行整理，保证其顺序性。而顺序性就可以最大程度保证数据的读取性能稳定。
LSM树核心就是放弃部分读能力，换取写入的最大化能力。LSM 树会将所有的数据插入、修改、删除等操作保存在内存中，当此类操作达到一定得数据量后，再批量地写入磁盘当中。而在写磁盘时，会和以前的数据做合并。在合并过程中，并不会像 B+ 树一样，在原数据的位置上修改，而是直接插入新的数据， 从而避免了随机写。
跳表
跳表是可以实现二分查找的有序链表
怎么实现的？
随机选 n/2 个元素做为一级索引、随机选 n/4 个元素做为二级索引、随机选 n/8 个元素做为三级索引，依次类推，一直到最顶层索引。这里每层索引的元素个数已经确定，且每层索引元素选取的足够随机，所以可以通过索引来提升跳表的查找效率。
为什么Redis选择使用跳表而不是红黑树来实现有序集合？Redis 中的有序集合(zset) 支持的操作：插入一个元素删除一个元素查找一个元素有序输出所有元素按照范围区间查找元素（比如查找值在 [100, 356] 之间的数据）其中，前四个操作红黑树也可以完成，且时间复杂度跟跳表是一样的。但是，按照区间来查找数据这个操作，红黑树的效率没有跳表高。按照区间查找数据时，跳表可以做到 O(logn) 的时间复杂度定位区间的起点，然后在原始链表中顺序往后遍历就可以了，非常高效。
视图，视图的优点（并不会降低效率）视图能否更新表？
视图的本质
视图是一种虚拟表，是数据逻辑，在物理上是不存在的，其内容与真实的表相似，包含一系列带有名称的列和行数据。但是，视图并不在数据库中以储存的数据值形式存在。行和列数据来自定义视图的查询所引用基本表（物理表）。
视图的作用
提高复杂SQL语句的复用性和表操作的安全性, 简化sql查询，提高开发效率。
视图使用者只能看到视图中所定义的数据，而不是视图所引用表中的数据，从而提高了数据库中数据的安全性。
视图的特点
a.视图的列可以来自不同的表，是表的抽象和在逻辑意义上建立的新关系。
b.视图是由基本表(实表)产生的表(虚表)。
c.视图的建立和删除不影响基本表。
d.对视图内容的更新(添加，删除和修改)直接影响基本表。
e.当视图来自多个基本表时，不允许添加和删除数据。
视图的更新
视图一般不可更新
可更新的情况：基本表的行列子集视图。
不可更新的情况：视图的属性来自函数，表达式，视图中有聚集函数，distinct项，视图中有嵌套查询，视图来自两个基表（join关联）。
语法格式
CREATE [OR REPLACE] [ALGORITHM={UNDEFIEND | MERGE | TEMPTABLE}]
VIEW view_name [(column_list)]
AS SELECT_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
创建视图的语句，是由多条子句构成的