MySQL面试问题整理二(非个人面试题，持续更新)

char(4)跟varchar(4)有何不同？

char跟varchar类型相似，都是用来存储字符串，但是他们的保存和检索方式不同。char属于固定长度的字符类型，而varchar属于可变长度的字符类型。

值	char(4)	存储需求	varchar(4)	存储需求
‘’	'  '	四个字节	‘’	一个字节
‘ab’	'ab'	四个字节	‘ab’	三个字节
‘abcd’	‘abcd’	四个字节	'abcd'	五个字节
'abcdefg'	‘abcd’	四个字节	'abcd'	五个字节

因此。char的处理速度比varchar快的多，但是其缺点是浪费存储空间。

 

作业二

熟练将inndob的特点描述出来

1、innodb支持行锁，行锁不占用内存结构。只有当发生锁冲突的时候才会占用内存结构，这一点跟SQLServer不一样，SQLServer是页锁，占用内存结构

2、innodb支持事务，提供了具有提交、回滚和崩溃恢复能力的事务安全

3、innodb支持主外键，但是该特性需要特别注意，假如对主表进行delete时，会访问外表，看该行数据是否存在。当对外表进行insert时，会访问主表，看该行数据是否存在。因此，很多高并发的数据库一般都不适使用外键

4、通过undo支持MVCC特性实现可重复读、写不阻塞读

5、支持redo，实现保护脏页、支持事务的一致性和持久性、崩溃恢复前滚的功能

6、支持大内存和多核CPU，例如inndob buffer pool和后台线程功能越来越细分

7、通过gap锁来实现dml一致性读，避免幻读

 

描述索引对表DML带来的核心危害，同时能够给出索引的合理数量。描述change buffer如何降低索引对DML带来的物理读、change buffer工作效率监控指标

 

      我们知道当对表做DML时不止是将数据修改在表中，还要对索引进行修改。 如果说某张表上索引的数量很多、索引不经常使用、索引的顺序跟主键的顺序完全不一致的话，可能会产生大量的物理读。因此一张表上建立索引的数量最好不超过6个，最好空值在三个以内。

     change buffer的作用是当要修改的索引数据对应的索引页在内存中，就将索引数据修改到索引页中，如果不在内存中，就先缓存到change buffer中，当对某一个索引页的数据超过比例时，将索引页调入内存中，做一次merge。提升系统的性能，降低索引对DML带来过多物理读的问题。

mysql> show engine innodb status \G

INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0

简单描述double write、自适应hash索引、刷新邻接页、异步IO

• double write解决了数据页的完整性问题，在刷新脏页时，先存储到double writer中(是两个1M的空间)，然后在写入到ibdata中，这两步骤完成之后，再写入到数据文件中。
• 自适应hash索引的特点是无序，没有树高，解决的是：如果二级索引被频繁访问的话，就是热数据，会将二级索引数据自动地生成到hash索引里面去，根据哈希函数计算出地址放在自适应hash索引里面，如果再次访问时，直接在hash索引里面取值，访问表数据，如果找不到的话，再继续走树高，而且只使用于等值查找
• 

 

• 刷新邻接页：是在刷新脏页时，会查看该脏页所在的区中的所有的脏页，并且一并刷新。普通情况下，刷新脏页到double write中，可能会不足1M，因此写的次数就会多，如果开启刷新邻接页功能的话，可能一次会刷新多个脏页，将1M空间占满，充分利用了double write每次写入1M的功能。在写入次数基本不变的情况下，增加了脏页写入的量。但是会带来问题，如果该脏页时热数据页，将其刷入到磁盘中，很快就会变成脏页，因此该特性没有太大的意义，建议关闭
• 异步IO：是Linux操作系统层面的一个功能，在数据库层面页需要打开。相对于同步IO来说，是在查找数据时，数据没有在内存中，需要将去请求放到读请求队列里面，多次的请求在一起排序，请求的数据页连接在一起的，就一次性读出来，减少多次物理读。

详细描述如何监控脏页写入速度是否满足性能要求，如果不满足要求 如何通过调整参数来加大写入力度？

 

执行show engine innodb status \G中关于日志的4行数据
LOG
---
Log sequence number 130048457  //日志生成量
Log flushed up to   130048457   //日志刷新到log file即磁盘的值
Pages flushed up to 130048457    //数据页刷新到磁盘的值，使用日志量来衡量的
Last checkpoint at  130048448    //对于数据页的每次刷新，不是马上记录刷新的检查点，而是隔一段时间刷新一次

因此2-3=脏页还没有刷新到磁盘的数量，因此这一部分所对应的日志还不能够被覆盖。因此这一部分的日志量不能够大于log file文件的30%~50%，否则脏页的写入速度就过慢，说明系统中存在过量的脏页

 

如果不满足要求，可以通过以下参数调整

1. 读取lru list,找脏页，刷入磁盘。innodb_lru_scan_depth此参数意义是在冷区一共寻找多少个数据页里面的脏页
2. 读取flush list,找脏页，刷入磁盘。因为flush list中挂的都是脏页。因此可以通过innodb_io_capacity_max告知最多可以刷新脏页的数量
3.  innodb_max_dirty_pages_pct：降低这个值，允许缓冲池多少是脏页，一旦超出此百分比，就会触发脏页的写