Mysql 知识点

1、索引 ----- 二叉树、平衡二叉树、b-tree、b+tree详解

二叉树具备如下性质：左子树的键值小于根的键值，右子树的键值大于根的键值。二叉树的查询效率就低了。所以若想二叉树的查询效率尽量高，须要这棵二叉树是平衡的。

平衡二叉树（AVL树）在符合二叉查找树的条件下，还知足任何节点的两个子树的高度最大差为1。

 

平衡多路查找树（B-Tree），系统从磁盘读取数据到内存时是以磁盘块（block）为基本单位的，位于同一个磁盘块中的数据会被一次性读取出来。InnoDB存储引擎中有页（Page）的概念，页是其磁盘管理的最小单位，默认16K。InnoDB每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小16KB。

缺点：每一个节点中不只包含数据的key值，还有data值。而每个页的存储空间是有限的，若是data数据较大时将会致使每一个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时一样会致使B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。

B+Tree相对于B-Tree有几点不一样：

非叶子节点只存储键值信息。

全部叶子节点之间都有一个链指针。

数据记录都存放在叶子节点中

在数据库中，B+Tree的高度通常都在2~4层。mysql的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只须要1~3次磁盘I/O操做。

2、汇集索引与非汇集索引

    汇集索引：数据行的物理顺序与列值（通常是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个汇集索引,通常指主键。

    非汇集索引：除汇集索引外其余都是的，包括普通索引，惟一索引，全文索引。叶子节点并不包含行记录的所有数据，而是存储相应行数据的汇集索引键。使用非汇集索引查询，而查询列中包含了其余该索引没有覆盖的列，那么他还要进行第二次的查询，查询节点上对应的数据行的数据。

    mysql索引通常建5-8个左右,索引过多，影响数据的操做(insert、update、delete)。优化建议使用联合索引。大字段值不建议建索引。建立索引和维护索引须要耗费时间，这个时间随着数据量的增长而增长；索引须要占用物理空间，不光是表须要占用数据空间，每一个索引也须要占用物理空间；当对表进行增、删、改、的时候索引也要动态维护，这样就下降了数据的维护速度。

3、如何解决非汇集索引的二次查询问题

 

  如创建符复合索引，只查询复合索引里的列的数据而不须要进行回表二次查询，注意最左原则

4、Mysql 索引失效   

    一、索引列不能储存null值，由于索引是有序的，建索引时没法肯定位置。

    二、查询时 采用is Null,只能全表扫描。

    三、数据库数据量较少时，mysql判断全表查询快时将不使用索引。

    四、like查询以%开头，类型隐士转换、列参与函数运算、使用or查询，联合索引非最左

 

5、MySQL中Myisam与Innodb的区别

 

InnoDB支持事物、支持行级锁，Myisam支持表级锁,不支持事物。

InnoDB支持MVCC、外键，Myisam不支持,支持全文索引。

Myisam查询表较快。

 

6、Innodb引擎四大特色

 

插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)

参考： http://www.javashuo.com/article/p-mdhengsl-hg.html

7、Innodb的事务与日志的实现方式

 隔离级别：读未提交(RU)、读已提交(RC)、可重复读(RR)、串行，mysql默承认重复读，mysql经过MVCC(多版本控制)和 Next-key lock(间隙锁)解决了幻读。

MVCC原理：经过在每行纪录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的建立时间，一个保存了行的过时时间（或删除时间），固然存储的并非实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会做为事务的版本号，用来和查询到的每行纪录的版本号进行比较。

MVCC是解决读写并行的幻读，而next-key lock 间隙锁 是解决写写并行的幻读。

Mysql日志：

慢查询日志（slow query log）:记录慢查询的日志文件

查询日志（general log）:记录全部对数据库请求的信息

重作日志（redo log）:

回滚日志（undo log）:

二进制日志（binlog）:用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步

错误日志（errorlog）:

中继日志（relay log）:

 

事务日志是经过redo和innodb的存储引擎插入缓冲（Innodb log buffer）来实现的，当开始一个事务的时候，会记录该事务的lsn(log sequence number)号; 当事务执行时，会往InnoDB存储引擎的日志

的日志缓存里面插入事务日志；当事务提交时，必须将存储引擎的日志缓冲写入磁盘（经过innodb_flush_log_at_trx_commit来控制），也就是写数据前，须要先写日志。这种方式称为“预写日志方式”。

8、MySQL数据库cpu飙升到500%的话他怎么处理？

 

列出全部进程，观察全部进程，多秒没有状态变化的(干掉)

查看超时日志或者错误日志

9、你是否作过主从一致性校验，若是有，怎么作的，若是没有，你打算怎么作？

 

主从一致性校验有多种工具 例如checksum、mysqldiff、pt-table-checksum等

 

10、大家数据库是否支持emoji表情，若是不支持，如何操做？

 

若是是utf8字符集的话，须要升级至utf8_mb4方可支持

 

11、Mysql索引查询优化

1.避免在索引列上使用IS NULL和IS NOT NULL，列字段尽可能要有默认值.

2.避免 SELECT *

3.千万不要 ORDER BY RAND()

4.在Join表的时候使用相同的类型并将其索引

5.当只要一行数据时使用 LIMIT 1

6.EXPLAIN 分析你的 SELECT 查询

7.每张表都设置ID

8.不要条件列进行函数处理

9.避免使用 or，like 等字段

10.选取最适用的字段属性，尽量减小定义字段宽度

11.用EXISTS替代IN、用NOT EXISTS替代NOT IN。

 

 

12、分布式事物理解

 

1.事物的ACID。原子性、一致性、隔离性、持久性

2.分布式系统中常常出现断电、网络异常、应用宕机等问题致使不一致问题。

3.执行事务的时候数据库首先会记录下这个事务的redo操做日志，而后才开始真正操做数据库，在操做以前首先会把日志文件写入磁盘，那么当忽然断电的时候，即便操做没有完成，在从新启动数据库时候，数据库会根据当前数据的状况进行undo回滚或者是redo前滚，这样就保证了数据的强一致性。

4.随着业务扩展，单库没法知足，需对数据库垂直分库，此时单个数据库ACID已经不能适应。

5.CAP定理，一致性，可用性，分区容错性。

6.程序中追求可用性要高于一致性，此时出现BASE定理,基本可用、软状态、最终一致性。

 

解决方案：

   

具体详解：    http://www.javashuo.com/article/p-ceuwqijs-mu.html

 

• 两阶段提交
• 基于可靠消息服务MQ的分布式事务，主流MQ不支持，
• TCC（两阶段+补偿）二阶段提交失败，嵌入回滚代码，Confirm/Cancel服务的幂等性保障。增大业务复杂度。
• 本地消息表：将分布式事务分红多个本地事物，而后经过异步mq发送消息保证一致性。

 

十3、mysql集群原理及方案

    采用主从复制，读写分离，主备模式

　　 　　　

 

主从复制原理：

   采用异步复制模型 
　　

十3、mysql索引条件下推ICP

       含义：mysql查询条件列在索引范围内，能够根据索引条件直接获取数据，能够减小存储引擎必须访问基表的次数以及MySQL服务器必须访问存储引擎的次数。

1.ICP 只适用于非汇集索引呀

2.只是适用于单表查询，非子查询

3.索引下推开关打开。