# 1. 上周重点难点回顾
## 1.1 索引
### 聚集索引构建B树的过程
### 辅助索引构建B树的过程
### 面试问题简易回答?
--- 请你简述,InnoDB 聚集索引和辅助索引的区别? *****
1. 一张表只能有一个聚集索引,最好是自增的数字列
2. 聚集索引叶子节点有序存储的整行数据
3. 辅助索引一个表可以有多个
4. 辅助索引叶子节点存储的是索引列的有序值+此列值的主键值
想要详细回答,整个两个索引构建的过程和配合使用,最好是画图说明
### 辅助索引细分
单列辅助索引
多列联合索引 *****
--- select xxxx from where a b c 都是等值查询,建索引有什么好的建议
1. 考虑联合索引
2. 排列问题? 唯一值多的放在
alter table t1 add idx(c,b,a)
select count(distinct a) from t1;
为什么?
优化器会自动按照索引建立的顺序,自动排列 where 条件的顺序,前提是都是等值或者in的。
如果出现其他方式条件,比如:
出现了> < 或者group by order by
怎么判断联合索引将来的优化效果?
1. 看执行计划
2. key_len
唯一索引
### 索引树高度问题
--- 索引树高度受到哪些原因影响?(开发规范)
1. 数据类型: char varchar enum
2. 数据量级问题: 分库 分表 分布式
3. 索引列值长度: 前缀索引
前缀索引
### explain(desc)重点回顾
--- 你在你们公司做过哪些优化(MySQL)?
1. 我在公司,主要是配合开发和业务人员,进行SQL优化和索引优化这块的工作
2. 我主要针对索引优化这块儿,做的工作比较多
3. 我一般都是配合两个数据库工具进行配优化
4. 第一个就是slowlog(自动收集慢语句),第二个工具是explain
5. 我通过之前做过的小案例来简单说明下我的优化思路
6. explain(desc)使用场景(面试题)
题目意思: 我们公司业务慢,请你从数据库的角度分析原因
1.mysql出现性能问题,我总结有两种情况:
(1)应急性的慢:突然夯住
应急情况:数据库hang(卡了,资源耗尽)
处理过程:
1.show processlist; 获取到导致数据库hang的语句
2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况
3. 建索引,改语句
(2)一段时间慢(持续性的):
1. 记录慢日志slowlog,分析slowlog
2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况
3. 建索引,改语句
7. 另外,我还做一部分存储引擎方面的优化。
我们有个业务是插入类的操作比较多,做过了一个存储引擎方面的优化。
将innoDB替换成了tokuDB
主要说说为什么会使用tokudb
。。。。。。
## 1.2 存储引擎
### InnoDB存储引核心特性
Transaction,Row Level Lock,MVCC,CSR,FK,HB,Replication
### 表空间管理
alter table t1 discard tablespace;
alter table t1 import tablespace;
### 事务特性
A 原子
C 一致
I 隔离
D 持久
### redo在ACID中的作用
重做日志,前滚日志。主要完成ACID中的D的特性。对AC也有一定的作用
存什么?
内存数据页变化的过程
### Undo在ACID作用
回滚日志,撤销日志。主要完成的ACID中的A,对CI也有一定的作用
### redo-CSR前滚
### Undo-CSR回滚
今日预计内容
# 2. 锁介绍
## 2.1 介绍
锁定的意思,提供的是ACID中,I方面的功能。需要配合UnDO+隔离级别一起来实现
## 2.2 InnoDB锁级别
行级锁
## 2.3 扩展内容(自己扩展)
Next LOCK
GAP LOCK
悲观锁:
乐观锁:
第一种:
select id from t where id > 9 and id < 12 order by id for update
访问顺序 :
1. id=9,gap [5-10]
2. 向右遍历 next-lock 10-15,发现10>9,停止扫描,但由于不是等值12,所有next-lock保持不变更gap
最终锁范围: [5-10],[10-15] ====》 [5-15]
第二种
select id from t where id > 9 and id < 12 order by id desc for update
由于order by desc 的存在,查询优化器为了避免再排一次序,会将查找顺序优化为先找id <12
所以访问顺序
1. id=12 ,gap[10-15]
2. 向左遍历,next-lock ,扫到5-10范围,发现10>9,继续向左,扫到0-5,发现5<9,停止扫描
但由于不是等值9,所有next-lock保持不变更gap
最终锁范围: [0-5],[5-10],[10-15] ===> [0-15]
工作中(优化章节):需要排查锁的争用、锁等待、死锁
# 3. 事务的隔离级别
影响到数据的读取,默认的级别是 RR模式.
transaction_isolation 隔离级别(参数)
负责的是,MVCC,读一致性问题
RU : 读未提交,可脏读,一般部议叙出现
RC(*****) : 读已提交,可能出现幻读,可以防止脏读.
RR(*****) : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR : 可串行化,可以防止死锁,但是并发事务性能较差
RR级别:解决了 不可重复读问题+幻读的现象
不可重复读问题是由 undo的快照技术来解决。
幻读现象是由:MVCC+GAP+next-lock
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常
select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.
例如:
[world]>select * from city where id=999 for update;
[world]>commit;
******欠一个问题,关于幻读模拟。******
# 4. InnoDB核心参数
## 4.1 双一标准之一(*****):innodb_flush_log_at_trx_commit=1
作用:
控制了redo buffer 刷写策略,是一个安全参数,是在5.6版本以上默认的参数
参数功能
1:每次事务提交,都会立即刷下redo到磁盘(redo buffer --每事务-->os buffer --每事务--磁盘)
0:表示当事务提交时,不立即做日志写入操作(redo buffer --每秒-->os buffer --每秒--磁盘)
2:每次事务提交引起写入文件系统缓存(redo buffer --每事务-->os buffer --每秒--磁盘)
## 4.2 Innodb_flush_method=(O_DIRECT, fdatasync)
作用:
控制了 redo buffer 和 data bufffer 刷写磁盘方式
最大安全模式:
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
最大性能模式:
innodb_flush_log_at_trx_commit=0
innodb_flush_method=fsync
## 4.3 关于redo设置
innodb_log_buffer_size= 128M 业务系统CPU压力有关
innodb_log_file_size=256 一般是1-2倍
innodb_log_files_in_group = 3 3-4组