文章目录

东篱南山

采菊东篱下,悠然现南山

面试篇--数据库

1.Mysql索引类型
1.1 按类型分
Hash索引 只支持精确查找,不支持范围查找,不支持排序
空间索引 只有MyISAM引擎支持,并且支持的
全文索引 主要用来查找文本中的关键字,而不是直接与索引中的值相比较。
Btree索引
1.2 聚集索引和非聚集索引
聚簇索引:聚簇索引是指索引的结构和排列规则是和实际数据的存储结构和排列规则是一样的,一张表只能有一个,
非聚簇索引:也就二级索引 非主键索引的叶子节点内容是主键的值。

2.Mysql优化
设计数据库时:数据库表、字段的设计,存储引擎
利用好MySQL自身提供的功能,如索引等
横向扩展:MySQL集群、负载均衡、读写分离
SQL语句的优化

3.Mysql B树怎么查询

建立索引注意点:
1.选择唯一性索引
2.为经常需要排序、分组和联合操作的字段建立索引
3.为常作为查询条件的字段建立索引
4.限制索引的数目
5.尽量使用数据量少的索引
6. 最左前缀匹配原则,非常重要的原则。

4.Mysql一个查询流程
分为两层:server层和引擎层
查询语句的执行流程如下:
连接器(负责跟客户端建立连接、获取权限、维持和管理连接)------>查询缓存------->分析器(词法分析、语法分析)------>优化器(判断使用什么索引、或者join表时表的连接顺序,虽然结果相同,但效率不同)------>执行器(先查询看看有没有对表的操作权限,然后再调引擎层的接口)
连接器(负责跟客户端建立连接、获取权限、维持和管理连接)---》查询缓存---》分析器(词法分析、语法分析)---》优化器---》权限校验---》执行器---》引擎
更新语句执行流程如下:分析器----》权限校验----》执行器---》引擎---redo log(prepare 状态---》binlog---》redo log(commit状态)
5.Mysql最左原则

6.Mysql主从同步
三个线程:
dump线程为每一个slave创建的
I/O线程、SQL线程活动在每一个slave上
主从同步流程:
1.Slave 服务器上执行start slave,开启主从复制开关,主服务器上会把sql都写入binLog中
2.slave 会先通过Master权限验证,并请求Master指定位置之后的binLog内容
3.Master把根据slave I/O线程发来信息,把后继的日志发给Slave
4.salve把Master发来的binlog 日志写入中继日志末端,并将新的 binlog 文件名和位置记录到 master-info 文件中,
5.SalveSql 线程检测到中继日志变化,将中继日志中的内容解析成Sql,在自己服务器上执行一边
主从复制模式
1.异步模式
2.半自动模式 主节点只需要接收到其中一台从节点的返回信息,就会commit;
3.全同步 主节点和从节点全部执行了commit并确认才会向客户端返回成功。
主从复制有三种方式:
1.基于Sql语句的复制
2.基于行的复制
3.混合模式

7.Mysql两种日志
1.redo log
引擎层的,是物理日志,记录的是“在某个数据页上做了什么修改”
redo log 是循环写的,先写日志,再写磁盘,空间固定会用完

2.bin log
  server层
  binlog 是逻辑日志,记录的是这个语句的原始逻辑
  binlog 是追加写入,文件写道一定大小,会切换下一个
  
为啥会有两种日志呢?
  redo是引擎层的,其他公司开发的,而binlog是server层的,redo打开事务,binlog写完再提交事务,两端提交,保证数据一致性

8.Mysql5.7新特性
1.JSON支持
2.安全性 root用户密码是随机的,默认连接走的SSL加密
9.分库分表(实现)
分库:
1.取模
2.顺序放入1--9999的放入1号库
分表:
1.水平拆分 单表数量太大,将表分割
2.竖直拆分 单表业务耦合太多,将表拆成几个表
带来的问题:
1.事务问题
由应用程序控制,保证最终一致性
可以做事务补偿机制
1.回调地址 2.消息通知
2.跨节点Join的问题
1.做一些反范式化的设计
2.由应用程序两次查询来处理
3.跨节点的count,order by,group by以及聚合函数问题
这种需要全部数据,在节点排序后,在应用程序段进行合并
4.ID问题
分库后ID不可重新
1.UUID 不推荐 UUID比较长 会比较战内存空间 建立索引和基于索引查询比较费时
2.Twitter的分布式自增ID算法Snowflake
机器码+时间+自增序号
使用中间件来做分库分表操作
Mycat shardingJDBC

10.脏读、幻读
脏读 一个事务读到另外一个事务未提交的数据
幻读 第一个事务查询N条 另外一个事务对数据做了新增或者删除操作,当第一个事务再次来查询时候 ,记录条数结果不一样,出现幻行

不可重复度 在一个事务内两次相同查询读到的数据内容是不一样的,因此称为是不可重复读。

11.简单的数据结构
栈、队列、链表、数组、哈希表、树
12.事务特性
原子性、一致性、隔离性、持久性
13.事务的隔离级别
读未提交 全都有
读已提交 没有脏读
可重复读 没有脏读和不可重复读
序列化
14.Mysql的乐观和悲观锁
select * from table lock in share mode -------乐观锁
select * from table for update ------悲观锁
15.查询explain
explain Sql
-- 结果:
id:选择标识符
select_type:表示查询的类型。 (简单查询,联合查询,子查询)
table:输出结果集的表
partitions:匹配的分区
type:表示表的连接类型 从最好到最差的连接类型为system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
possible_keys:表示查询时,可能使用的索引
key:表示实际使用的索引
key_len:索引字段的长度
ref:列与索引的比较
rows:扫描出的行数(估算的行数)
filtered:按表条件过滤的行百分比
Extra:执行情况的描述和说明
16.慢查询
slow_query_log

17.红黑树为啥那样设计?
首先聊一下二叉搜索树,主要特点是左节点比根节点小,右节点比根节点大,并且左右子树都是二叉搜索树。缺点是在极端情况下,比如插入都是有序的,就会出现退化的情况有序序列树退化成链表,此时,要想让树的节点平均分布就需要平衡树了,红黑树就是平衡树的一种(平衡二叉搜索树)。然后,一棵树的查询性能取决于树的高度,红黑树让树尽可能平衡,就是为了降低树的高度。
18.什么是B树?
B树是一种平衡多路搜索树,他的每个节点可以拥大于等于2个子节点,M路的B树最多能拥有M个子节点,一个节点中有 m 个子节点则存在 m-1 个记录,记录按照递增次序进行排列,叶节点都在同一层上。B树之所以多路(也就是每个节点上可存多个记录)是为了降低高度,路数越多,树高度越低,查询性能也高。但也不能是无限的,否则就退化成有序数组了。
19.什么是B+树?
B+树是在B树基础上进行改造,他的数据都在叶子结点,同时叶子结点之间还加了指针形成一个链表。
20.为什么用B+树存储索引而不用B树?
这也是和业务场景相关的,一般去数据库查询数据,不一定只选一条,很多时候会选多条数据,在查多条情况下,B树需要做局部的中序遍历,可能要跨层访问。而B+树由于所有数据都在叶子结点,不用跨层,同时由于有链表结构,只需要找到首尾,通过链表就能把所有数据取出来了。
21.为什么用B+树做索引?
主要还是为了减少磁盘中机械臂的运动,增加定位的效率


标题:面试篇--数据库
作者:zc1249274251
地址:https://www.fanyueba.com/articles/2019/09/26/1569470612719.html