一份mysql面试题

1， mysql的复制原理以及流程。

（1）先问基本原理流程，3个线程以及之间的关联。

　　答：Mysql复制的三个线程：主库线程，从库I/O线程，从库sql线程；

　　　　复制流程：（1）I/O线程向主库发出请求

　　　　　　　　　（2）主库线程响应请求，并推binlog日志到从库

　　　　　　　　　（3）I/O线程收到线程并记入中继日志

　　　　　　　　　（4）Sql线程从中继日志读取sql，并记入从库binlog日志，flush进硬盘；

（2）再问一致性延时性，数据恢复；

　　答：（1）主从复制一致性由binlog执行顺序保证（timespan+pos）；

　　　　　　 日志越详细，主从一致性越容易保证；

　　　　（2）延时性：延时表现为behind_master_pos后面的数字，其实并不准确；

　　　　　　　　　　5.5.30以前版本都属于异步复制，因此都有延时。因为是主库执行完成后从库才执行，一先一后就有了延迟；

　　　　　　　　　　主从延迟的准确计算方法是：延迟时间=从库执行sql完成的时刻-主库开始执行sql的时间；

　　　　（3）数据恢复：备份时记录的binlog位置点（timespan+pos）；

（3）再问各种工作遇到的复制bug的解决方法；

　　答：这个问题感觉描述并不准确，不清楚是主从复制故障还是bug；

　　　　故障一般由于主键冲突，链接不上主库，找不到对应的binlog位置等引起；

　　　　解决方法是跳过冲突，检查主从链接，找正确的pos；

　　　　bug不常见，笔者碰到过一次，分享如下：

　　　　　　环境：主库从库都是虚机，每十分钟与宿主机同步一次时间，大约每次与主机相差2秒；

　　　　　　表现：从库复制时重复执行两秒之内的日志；

　　　　　　　　　从库show slave status\G，behind_master_pos在60000和0之间循环，每两秒一次；

2， mysql中myisam与innodb的区别，至少5点。

　　（1） 问5点不同

　　　　答：1、 存储成本不一样，存储限制不一样；

　　　　　　2、CPU使用成本不一样，innodb缓存数据和索引；

　　　　　　3、锁粒度不一样，支持MVCC；

　　　　　　4、缓存机制不一样(buffer_pool和key_buffer)

　　　　　　5、事务支持；

　　　　　　6、索引支持：全文索引(myisam),外键(innodb)，hash(innodb)

　　　　　　7、读写速度；

　　　　　　8、备份；

　　（2）、问各种不同mysql版本的2者的改进；　　　　

　　　　　　最近测5.1.38和5.5.35

　　　　　　Innodb:（1）adeptive_innodb_index可控；

　　　　　　　　　　（2）innodb变为默认引擎；

　　　　　　　　　　（3）更快的innodb插入；

　　　　　　　　　　（4）读写线程数目；

　　　　　　　　　　（5）半同步复制；

　　　　　　　　　　（6）performance_schame

　　　　　　Myisam（1）

　　（3）2者的索引的实现方式；

　　　　

3，问mysql中varchar与char的区别以及varchar(50)中的30代表的涵义。

　　（1） varchar与char的区别

　　　　答：变长和固定长度

      （2）varchar(50)中50的涵义

           答： 字节最大长度50

　　（3） int（20）中20的涵义

　　　　答：十进制最大位数；

      （4）为什么MySQL这样设计？

　　　　答：适应不同需求；

4，问了innodb的事务与日志的实现方式。 

　　（1）有多少种日志

　　　　答：5种，binlog,查询日志，慢查询，错误日志，中继日志

　　（2）日志的存放形式

　　　　答：Binlog,中继日志都是二进制；

　　　　　　其他三种是文本形式；

　　（3）事务是如何通过日志来实现的，说得越深入越好。

　　　　答：Innodb日志需要开启显式提交，默认是关闭的；

　　　　　　首先了解日志过程。缓存进log_buffer,每秒或每十秒刷入redo_log，提交后刷入硬盘

　　　　　　事务日志会在innodb_buffer_pool页中标记行是否更新，删除，commit后刷入硬盘，没有commit则不计入磁盘，属于脏数据；

5，问了mysql binlog的几种日志录入格式以及区别

　　（1）   各种日志格式的涵义

　　　　答：三种日志格式 ：statement,row,mixed

　　　　　　每一条DML操作的sql都被计入statement日志；

　　　　　　每条DML操作的sql被记录为对每条数据的操作，计入row日志；

　　　　　　mixed日志是上面两种的混合

　　（2）   适用场景

　　　　答：1、Statement，优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能；

　　　　　　　　　　　　　　缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能　　　　　　　　　　　　　　　　　在slave得到和在master端执行时候相同 的结果；

　　　　　　　　　　　　　　　　　某些特定函数功能会引起复制问题,比如sleep()函数， last_insert_id()；

　　　　　　　　　　　　　　　　　某些函数无法计入复制日志： LOAD_FILE()

　　　　　　2、Row模式，优点：不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了；

　　　　　　　　　　　　  缺点：产生大量的日志，大量日志造成io开销大；

　　　　　　3、mixed模式，一般的语句修改使用statment格式保存binlog，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL根据sql来选择日志记录　　　　　　　　格式，表结构变更的时候就会以statement模式来记录，update或者delete等修改数据的语句，还是会记录所有行的变更；

      （3）结合第一个问题，每一种日志格式在复制中的优劣。

6，问了下mysql数据库cpu飙升到500%的话他怎么处理？

　　答：（1）多实例的服务器，先top查看是那一个进程，哪个端口占用CPU多；

　　　　（2）show processeslist查看是否由于大量并发，锁引起的负载问题；

　　　　（3）否则，查看慢查询，找出执行时间长的sql；explain分析sql是否走索引，sql优化；

　　　　（4）再查看是否缓存失效引起，需要查看buffer命中率；

7， sql优化。

        （1）explain出来的各种item的意义

　　　　答：Select_type：所使用的查询类型，主要有以下这几种查询类型：

　　　　　　　　DEPENDENT SUBQUERY：子查询内层的第一个SELECT，依赖于外部查询的结果集。

　　　　　　　　DEPENDENT UNION：子查询中的UNION，且为UNION中从第二个SELECT开始的后面所有SELECT，同样依赖于外部查询的结果集。

　　　　　　　　PRIMARY：子查询中的最外层查询，注意并不是主键查询。

　　　　　　　　SIMPLE：除子查询或UNION之外的其他查询。

　　　　　　　　SUBQUERY：子查询内层查询的第一个SELECT，结果不依赖于外部查询结果集。

　　　　　　　　UNCACHEABLE SUBQUERY：结果集无法缓存的子查询。

　　　　　　　　UNION：UNION语句中第二个SELECT开始后面的所有SELECT，第一个SELECT为PRIMARY。

　　　　　　　　UNION RESULT：UNION 中的合并结果。

　　　　　　Table：显示这一步所访问的数据库中的表的名称。

　　　　　　Type：告诉我们对表使用的访问方式，主要包含如下集中类型。

　　　　　　　　const：读常量，最多只会有一条记录匹配，由于是常量，实际上只须要读一次。

　　　　　　　　eq_ref：最多只会有一条匹配结果，一般是通过主键或唯一键索引来访问。

　　　　　　　　fulltext：进行全文索引检索。

　　　　　　　　index：全索引扫描。

　　　　　　　　index_merge：查询中同时使用两个（或更多）索引，然后对索引结果进行合并（merge），再读取表数据。

　　　　　　　　index_subquery：子查询中的返回结果字段组合是一个索引（或索引组合），但不是一个主键或唯一索引。

　　　　　　　　rang：索引范围扫描。

　　　　　　Possible_keys：该查询可以利用的索引。如果没有任何索引可以使用，就会显示成null，这项内容对优化索引时的调整非常重要。

　　　　　　Key：MySQL Query Optimizer 从 possible_keys 中所选择使用的索引。

　　　　　　Key_len：被选中使用索引的索引键长度。

　　　　　　Ref：列出是通过常量（const），还是某个表的某个字段（如果是join）来过滤（通过key）的。　　

　　　　　　Rows：MySQL Query Optimizer 通过系统收集的统计信息估算出来的结果集记录条数。

　　　　　　Extra：查询中每一步实现的额外细节信息，主要会是以下内容。　　　　　　　

　　　　　　注：http://www.cnblogs.com/hustcat/articles/1579244.html

        （2）profile的意义以及使用场景。

        （3）explain中的索引问题。

 

8,  备份计划，mysqldump以及xtranbackup的实现原理，

 

      答： Mysqldump：先锁所有表，然后把表中每条sql拼接为insert语句，一页为一小段，

 

                                   备份结构为：表结构+insert

 

             Xtrabackup分对innodb和myisam引擎表的备份；

　　　　　　　　myisam：锁表进行copy；

　　　　　　　　innodb： Xtrabackup备份Innodb是利用了innodb的crach_recovery功能；

 

                                   Crash_recovery是对事务日志，commit的sql记入datafile，没有commit的则回滚，这点在innodb启动时被应用；

 

                                   Xtrabackup由三个线程进行：

 

       　　　　　　　　　　　　线程1，copy innodb的页，每秒copy1M，64页，copy过程中页数据是rw的，利用Innodb的内置表进行copy；

 

　　　　　　　　　　　　　　 线程2，监控copy过程中页数据是否正常，正常则copy，不正常则再copy一次，最多重复10次；

 

                                   　　线程3，监控logfile，有变化则立刻copy走；

 

                                   Copy结束后，记录位置点；

 

             增量备份:检查与上次备份，哪些页有变化，比较上次备份页的lsn与当前页lsn大小，有变化则copy走，copy结束后，则记录最后的位置点；

 

　　（1）备份计划

 

　　　　Dump，每天备份一次，每15分钟日志备份；

 

　　　　Xtranbackup：每三天备份一次，每天一次增量备份，每15分钟一次日志备份；

 

　　（2）备份恢复时间

 

 　　　　这个真心没看懂问的什么意思。

 

　　（3） 备份恢复失败如何处理

 

　　　　答：检查表是否损坏，正常则再重新备份恢复；

 

9，  500台db，在最快时间之内重启。
 
10，在当前的工作中，你碰到到的最大的mysql db问题是？

 

11，  innodb的读写参数优化

 

　　（1）   读取参数，global buffer pool以及 local buffer 

 

　　　　　　Innodb_buffer_pool_size，理论上越大越好，建议服务器50%~80%，实际为数据大小80%~90%即可；

 

　　　　　　Innodb_read_io_thread，根据处理器内核数决定；

 

　　　　　　Read_buffer_size;

 

　　　　　　Sort_buffer_size

 

　　（2）   写入参数

 

　　　　　　Insert_buffer_size；

 

　　　　　　Innodb_double_write；

 

　　　　　　Innodb_write_io_thread

 

　　　　　　innodb_flush_method

 

　　（3）   与IO相关的参数

 

　　　　　　Innodb_log_buffer_size

 

　　　　　　innodb_flush_log_at_trx_commit

 

　　　　　　innodb_file_io_threads

 

　　　　　　innodb_max_dirty_pages_pct

 

    （4）缓存参数以及缓存的适用场景

 

 

12 ，请简洁地描述下MySQL中InnoDB支持的四种事务隔离级别名称，以及逐级之间的区别？

       未提交读（uncommited read），提交读（commited read），重复读（repeatable read），串行读（serializable）

 

       这四种隔离级别逐个提高，区别表现在脏读，非重复读，幻读这三点，还有对并发的影响，隔离级别越高，并发性越差；

       所谓脏读，就是同一事务中，会读取还未提交的事务修改的数据；

       非重复读，是指在同一事务中，在t1时刻，读取某行数据时为A，t2时刻读取同一行数据时，由于其他事务更新，这行数据已经发生改变；

       幻读，是指在同一事务中，同一查询多次进行时，由于其他事务的提交，插入新纪录，导致每次查询的结果都不同；

 　　

　　区别在于：

       未提交读：会造成脏读，非重复读，幻读；

       提交读：不会造成脏读，但是会有非重复读，幻读；

       重复读：可能会造成幻读；

       串行读：不会造成脏读，非重复读，幻读；

 

13，表中有大字段X（例如：text类型），且字段X不会经常更新，以读为为主，请问

（1）    您 是选择拆成子表，还是继续放一起？

a)      放在子表中

（2）    写出您这样选择的理由？

a)       

14，MySQL中InnoDB引擎的行锁是通过加在什么上完成（或称实现）的？为什么是这样子的？ 

       Innodb的行锁是加在索引实现的，如果查询未通过索引进行，innodb将使用表锁

       原因是，innodb的索引和数据是不分开的；共同作为B+树的子节点；