1、JAVA
2、计算机网络
3、计算机体系结构
4、数据库
5、计算机租场原理
6、软件工程
7、大数据
8、英文 自我介绍
4. 数据库
1. B+树相对于B树的区别及优势
- B树中有重复元素，B树没有重复元素
- B树种每个节点都存储了key和data，B+树内节点去掉了其中指向数据(data record)的指针，使得每个节点中可以存放更多的key，意味着树的高度可以被压缩
- B+树的叶子节点是链表形式，可以更方便的进行顺序遍历。而B树相邻的元素可能在内存中不相 邻，所以缓存命中性没有B+树好。
- B+树查找更稳定，都是从根节点到叶节点
2、聚簇索引和非聚簇索引
聚簇索引（一级索引）：
将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据物理有序，叶子节点保存了数据
mysql中聚簇索引的设定: 聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。
InnoDB 只聚集在同一个页面中的记录。包含相邻健值的页面可能相距甚远。
非聚簇索引（辅助索引、二级索引）：
将数据与索引分开存储，索引结构的叶子节点指向了数据对应的位置
叶子节点保存的是id（主键），然后回表（二次查找）
- undo log
回滚操作而诞生的机制，当出现错误时，根据undo log进行回滚。
undo：增删改 update delete insert
undo Log两大类：
新增操作，事务提交后可以直接删除
update和delete，配合mvcc使用
- undo log和redo log的区别
redo log解决的是系统崩溃的问题，当是一个事务提交后，只进行了一半操作，可以使用redo log日志
重做。所以，事务提交后，先写redo log(应该是先写undo log)，然后再执行相应的操。
只有在日志记录全部都安全落盘，然后在最后写上“Commit Record”后，表示所有的操作记录我都写完啦。
undo log:
redo log太慢，没有写完redo log, 数据库是不能写的。
即使事务提交前磁盘 I/O 有足够空闲、即使某个事务修改的数据量非常庞大，占用大量的内存缓冲，无论何种理由，都决不允许在事务提交之前就开始修改磁盘上的数据，万一系统崩溃了，数据出差谁负责呀？
这就需要引入Undo Log（回滚日志），在偷摸写入数据之前，必须先在Undo Log中记录都写入了什么数据，改了什么地方，到时候事务回滚了，就按照Undo Log日志，一条条恢复到原来的样子，就像没有改过一样。
Undo Log还有一个作用，就是实现多个行版本控制(MVCC)，当读取的某一行被其他事务锁定时，它可以从 Undo Log 中获取该行记录以前的数据是什么，从而提供该行版本信息，让用户读取。
4、 MVCC部分
多版本并发控制。避免并发操作出现问题，使得数据一致。
可以实现读已提交（解决脏读）和可重复读（解决脏读和不可重复读），但是mvcc不能解决幻读，需要用锁机制解决。
使用undo log和readview来解决
- 实现读已提交：
每个select都创建一个readview - 实现可重复读：
一个事务种的第一个select创建readview，之后的select不再创建
查找undo log种的版本（四步）：
innodb种会记录未提交事务的id，从小到大。
- 判断该版本是否为当前事务创建
- 判断是否比最小的小
- 判断是否比最大（max_trx_id）的大
- 。。。。
5、主从复制
主：负责写
从：负责读
数据如何同步的？
数据延时问题解决：
主服务器：先写binlog，再同步过去，发送等待slave的ACK回应，再写数据。
6、 分库分表
- 水平拆分
- 垂直拆分
插数据流程：先找库，再找表。
奇数偶数分库，取余操作分表。
7、sql执行过程s
8、 锁
- S锁，共享锁，读锁
select user from table where id < 10 lock in share mode; - X锁，排他锁，写锁
select from table for update;
锁没有mvcc效率高。
意向共享锁（IS）
意向排他锁（IX）
意向锁用来判断是否加锁了。
死锁
myisam没有死锁
9、 - 索引失效
10、 - 数据库调优
- 查看索引是否失效
like %开头
字符串没有单引号
联合索引没有符合最左匹配原则
使用了range方位查找
or左右只有一个主键字段。 - 优化数据库的结构
使用频率低的表作为新表
使用频率高的字段冗余为一个表
需要联合查询的表建立中间表 - 分解关联查询
- 优化limit分页
原来：select * from table limit 10000, 10
改成：select * from table where id >= 10000 limit 10
这样使用了主键，可以优化。
11、 - explain中的字段
- id 查询中的序列号
- select_type: 表示 select 查询的类型，主要是用于区分各种复杂的查询，例如： 普通查询 、 联
合查询 、 子查询 等。 - table：表名
- type（重要）:从上到下，最好–>最差
system：只有一行或者空表，基本不可能存在
const：表中只有一行记录匹配，主键或者unique索引
eq_ref：联合查找，前面的唯一对应后面的表
ref：匹配多行
fulltext：全文索引，优先级很高，比普通索引优先级高
ref_or_null：和ref类似
index_merge
unique_subquery
index_subquery
range
index: 索引全表扫描，把索引从头到尾扫一遍。这里包含两种情况：一种是查询使用了覆盖索引，那么它只需要扫描索引就可以获得数据，这个效率要比全表扫描要快，
All: 全表扫描，没有使用索引。 - filtered：查出的结果/内部查询时所读的行数的百分比,100%说明大概率走了索引
- extra（重要）：distinct：在select部分使用了distinc关键字
Using filesort：当 Extra 中有 Using filesort 时,不能通过索引顺序达到排序效果.
Using index：“覆盖索引扫描”, 表示查询在索引树中就可查找所需数据, 不用扫描表数据文件,往往说明性能不错
Using temporary： 查询有使用临时表, 一般出现于排序, 分组和多表 join 的情况, 查询效率不高, 建议优化.
