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 的情况, 查询效率不高, 建议优化.