数据库常见面试题（二）

（根据自己的面试经验总结的知识点，内容比较浅显，有问题的地方欢迎指正呀）

四、存储引擎

1.MySQL常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别?

2、两种存储引擎的大致区别表现在：

1. InnoDB支持事务，MyISAM不支持， 这一点是非常之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而MyISAM就不可以了。
2. MyISAM适合查询以及插入为主的应用。
3. InnoDB适合频繁修改以及涉及到安全性较高的应用。
4. InnoDB支持外键，MyISAM不支持。
5. 从MySQL5.5.5以后，InnoDB是默认引擎。
6. InnoDB不支持FULLTEXT类型的索引。
7. InnoDB中不保存表的行数，如select count() from table时，InnoDB需要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含where条件时MyISAM也需要扫描整个表。
8. 对于自增长的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中可以和其他字段一起建立联合索引。
9. DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的 删除，效率非常慢。MyISAM则会重建表。
10. InnoDB支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like ‘%lee%’。

3、MySQL存储引擎MyISAM与InnoDB如何选择

MySQL有多种存储引擎，每种存储引擎有各自的优缺点，可以择优选择使用：MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE。
虽然MySQL里的存储引擎不只是MyISAM与InnoDB这两个，但常用的就是两个。
关于MySQL数据库提供的两种存储引擎，MyISAM与InnoDB选择使用：

1. INNODB会支持一些关系数据库的高级功能，如事务功能和行级锁，MyISAM不支持。
2. MyISAM的性能更优，占用的存储空间少，所以，选择何种存储引擎，视具体应用而定。
   如果你的应用程序一定要使用事务，毫无疑问你要选择INNODB引擎。但要注意，INNODB的行级锁是有条件的。在where条件没有使用主键时，照样会锁全表。比如DELETE FROM mytable这样的删除语句。
   如果你的应用程序对查询性能要求较高，就要使用MyISAM了。MyISAM索引和数据是分开的，而且其索引是压缩的，可以更好地利用内存。所以它的查询性能明显优于INNODB。压缩后的索引也能节约一些磁盘空间。MyISAM拥有全文索引的功能，这可以极大地优化LIKE查询的效率。
   有人说MyISAM只能用于小型应用，其实这只是一种偏见。如果数据量比较大，这是需要通过升级架构来解决，比如分表分库，而不是单纯地依赖存储引擎。
   现在一般都是选用innodb了，主要是MyISAM的全表锁，读写串行问题，并发效率锁表，效率低，MyISAM对于读写密集型应用一般是不会去选用的。
   MEMORY存储引擎
   MEMORY是MySQL中一类特殊的存储引擎。它使用存储在内存中的内容来创建表，而且数据全部放在内存中。这些特性与前面的两个很不同。
   每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构。而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率。值得注意的是，服务器需要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要了，可以释放内存，甚至删除不需要的表。
   MEMORY默认使用哈希索引。速度比使用B型树索引快。当然如果你想用B型树索引，可以在创建索引时指定。

注意，MEMORY用到的很少，因为它是把数据存到内存中，如果内存出现异常就会影响数据。如果重启或者关机，所有数据都会消失。因此，基于MEMORY的表的生命周期很短，一般是一次性的。

4、MySQL的MyISAM与InnoDB两种存储引擎在，事务、锁级别，各自的适用场景?

1. 事务处理上方面
   MyISAM：强调的是性能，每次查询具有原子性,其执行数度比InnoDB类型更快，但是不提供事务支持。
   InnoDB：提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
2. 级别
   MyISAM：只支持表级锁，用户在操作MyISAM表时，select，update，delete，insert语句都会给表自动加锁，如果加锁以后的表满足insert并发的情况下，可以在表的尾部插入新的数据。
   InnoDB：支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁，只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的。

五、优化

1.查询语句不同元素（where、jion、limit、group by、having等等）执行先后顺序?

1. 查询中用到的关键词主要包含六个，并且他们的顺序依次为 select–from–where–group by–having–order by
   其中select和from是必须的，其他关键词是可选的，这六个关键词的执行顺序 与sql语句的书写顺序并不是一样的，而是按照下面的顺序来执行
   from:需要从哪个数据表检索数据
   where:过滤表中数据的条件
   group by:如何将上面过滤出的数据分组
   having:对上面已经分组的数据进行过滤的条件
   select:查看结果集中的哪个列，或列的计算结果
   order by :按照什么样的顺序来查看返回的数据
2. from后面的表关联，是自右向左解析 而where条件的解析顺序是自下而上的。
   也就是说，在写SQL语句的时候，尽量把数据量小的表放在最右边来进行关联（用小表去匹配大表），而把能筛选出小量数据的条件放在where语句的最左边 （用小表去匹配大表）

2.使用explain优化sql和索引?

对于复杂、效率低的sql语句，我们通常是使用explain sql 来分析sql语句，这个语句可以打印出，语句的执行。这样方便我们分析，进行优化
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL
all:full table scan ;MySQL将遍历全表以找到匹配的行；
index: index scan; index 和 all的区别在于index类型只遍历索引；
range：索引范围扫描，对索引的扫描开始于某一点，返回匹配值的行，常见与between ，等查询；
ref：非唯一性索引扫描，返回匹配某个单独值的所有行，常见于使用非唯一索引即唯一索引的非唯一前缀进行查找；
eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常用于主键或者唯一索引扫描；
const，system：当MySQL对某查询某部分进行优化，并转为一个常量时，使用这些访问类型。如果将主键置于where列表中，MySQL就能将该查询转化为一个常量。
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key： 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MySQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MySQL忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MySQL认为必须检查的用来返回请求数据的行数
Extra：关于MySQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MySQL根本不能使用索引，结果是检索会很慢。

3.MySQL慢查询怎么解决?

slow_query_log 慢查询开启状态。
slow_query_log_file 慢查询日志存放的位置（这个目录需要MySQL的运行帐号的可写权限，一般设置为MySQL的数据存放目录）。
long_query_time 查询超过多少秒才记录为慢查询。
1） 索引没起作用的情况

1. 使用LIKE关键字的查询语句：在使用LIKE关键字进行查询的查询语句中，如果匹配字符串的第一个字符为“%”，索引不会起作用。只有“%”不在第一个位置索引才会起作用。
2. 使用多列索引的查询语句：MySQL可以为多个字段创建索引。一个索引最多可以包括16个字段。对于多列索引，只有查询条件使用了这些字段中的第一个字段时，索引才会被使用。
   2）优化数据库结构：
   合理的数据库结构不仅可以使数据库占用更小的磁盘空间，而且能够使查询速度更快。数据库结构的设计，需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。
3. 将字段很多的表分解成多个表 ： 对于字段比较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。
4. 增加中间表： 对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，把需要经常联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。
   3）分解关联查询： 将一个大的查询分解为多个小查询是很有必要的。

4.SQL语句优化小技巧

1. DDL优化: 1. 通过禁用索引来提供导入数据性能,这个操作主要针对有数据的表追加数据 ；2. 关闭唯一校验 ；3. 修改事务提交方式(导入)(变多次提交为一次)
2. DML优化: 把多条插入的语句合并为一条(变多次提交为一次)
3. DQL优化:
4. Order by 优化
5. 多用索引排序
6. 普通结果排序(非索引排序)
7. Group by 优化:如果对排序的结果没有排序的需求，可以考虑在其后面加上order by nul
   子查询优化
8. Or优化:
   1.or两边都是用索引字段做判读,性能好
   2.or两边,有一边不用,性能差
   3.如果name=”a” or name=”b”,这种方式,索引失效
   Limit优化

六、数据库锁

1.mysql都有什么锁，死锁判定原理和具体场景，死锁怎么解决?

MySQL有三种锁的级别：页级、表级、行级。
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

2.什么情况下会造成死锁?

1. 什么是死锁？
   是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。
   表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
   死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。
   那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。
2. 死锁的解决办法?
   1.查出的线程杀死 kill
   SELECT trx_MySQL_thread_id FROM information_schema.INNODB_TRX;
   2.设置锁的超时时间
   Innodb 行锁的等待时间，单位秒。可在会话级别设置，RDS 实例该参数的默认值为 50（秒）。
   生产环境不推荐使用过大的 innodb_lock_wait_timeout参数值
   该参数支持在会话级别修改，方便应用在会话级别单独设置某些特殊操作的行锁等待超时时间，如下：
   set innodb_lock_wait_timeout=1000; —设置当前会话 Innodb 行锁等待超时时间，单位秒。
3. 指定获取锁的顺序

3.有哪些锁（乐观锁悲观锁），select 时怎么加排它锁?

3.1、乐观锁和悲观锁

1. 悲观锁（Pessimistic Lock）:
   悲观锁特点:先获取锁，再进行业务操作。
   即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。通常所说的“一锁二查三更新”即指的是使用悲观锁。通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … for update操作来实现悲观锁。当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。
   补充：
   不同的数据库对select for update的实现和支持都是有所区别的，
   oracle支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，MySQL就没有no wait这个选项。
   MySQL还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。因此如果在MySQL中用悲观锁务必要确定走了索引，而不是全表扫描。
2. 乐观锁（Optimistic Lock）:
   1.乐观锁，也叫乐观并发控制，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，那么当前正在提交的事务会进行回滚。
   2.乐观锁的特点先进行业务操作，不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。
   乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。
   3.一般的做法是在需要锁的数据上增加一个版本号，或者时间戳，
   实现方式举例如下：
   乐观锁（给表加一个版本号字段） 这个并不是乐观锁的定义，给表加版本号，是数据库实现乐观锁的一种方式。
   SELECT data AS old_data, version AS old_version FROM …;
   根据获取的数据进行业务操作，得到new_data和new_version
   UPDATE SET data = new_data, version = new_version WHERE version = old_version
   if (updated row > 0) {
   // 乐观锁获取成功，操作完成
   } else {
   // 乐观锁获取失败，回滚并重试
   }
   注意：
   乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能
   乐观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方。
   总结：
   悲观锁和乐观锁是数据库用来保证数据并发安全防止更新丢失的两种方法，例子在select … for update前加个事务就可以防止更新丢失。悲观锁和乐观锁大部分场景下差异不大，一些独特场景下有一些差别，一般我们可以从如下几个方面来判断。
   响应速度： 如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁。’
   冲突频率： 如果冲突频率非常高，建议采用悲观锁，保证成功率，如果冲突频率大，乐观锁会需要多次重试才能成功，代价比较大。
   重试代价： 如果重试代价大，建议采用悲观锁。

七、其他

1.数据库的主从复制

主从复制的几种方式:

1. 同步复制:
   所谓的同步复制，意思是master的变化，必须等待slave-1,slave-2,…,slave-n完成后才能返回。 这样，显然不可取，也不是MySQL复制的默认设置。比如，在WEB前端页面上，用户增加了条记录，需要等待很长时间。
2. 异步复制:
   如同AJAX请求一样。master只需要完成自己的数据库操作即可。至于slaves是否收到二进制日志，是否完成操作，不用关心,MySQL的默认设置。
3. 半同步复制:
   master只保证slaves中的一个操作成功，就返回，其他slave不管。 这个功能，是由google为MySQL引入的。

2.数据库主从复制分析的 7 个问题?

1、master的写操作，slaves被动的进行一样的操作，保持数据一致性，那么slave是否可以主动的进行写操作？
假设slave可以主动的进行写操作，slave又无法通知master，这样就导致了master和slave数据不一致了。因此slave不应该进行写操作，至少是slave上涉及到复制的数据库不可以写。实际上，这里已经揭示了读写分离的概念。
2、主从复制中，可以有N个slave,可是这些slave又不能进行写操作，要他们干嘛？
实现数据备份:
类似于高可用的功能，一旦master挂了，可以让slave顶上去，同时slave提升为master。
异地容灾:比如master在北京，地震挂了，那么在上海的slave还可以继续。
主要用于实现scale out,分担负载,可以将读的任务分散到slaves上。
【很可能的情况是，一个系统的读操作远远多于写操作，因此写操作发向master，读操作发向slaves进行操作】
3、主从复制中有master,slave1,slave2,…等等这么多MySQL数据库，那比如一个JAVA WEB应用到底应该连接哪个数据库?
我们在应用程序中可以这样，insert/delete/update这些更新数据库的操作，用connection(for master)进行操作，
select用connection(for slaves)进行操作。那我们的应用程序还要完成怎么从slaves选择一个来执行select，例如使用简单的轮循算法。
这样的话，相当于应用程序完成了SQL语句的路由，而且与MySQL的主从复制架构非常关联，一旦master挂了，某些slave挂了，那么应用程序就要修改了。能不能让应用程序与MySQL的主从复制架构没有什么太多关系呢？
找一个组件，application program只需要与它打交道，用它来完成MySQL的代理，实现SQL语句的路由。
MySQL proxy并不负责，怎么从众多的slaves挑一个？可以交给另一个组件(比如haproxy)来完成。
这就是所谓的MySQL READ WRITE SPLITE，MySQL的读写分离。
4、如果MySQL proxy , direct , master他们中的某些挂了怎么办？
总统一般都会弄个副总统，以防不测。同样的，可以给这些关键的节点来个备份。
5、当master的二进制日志每产生一个事件，都需要发往slave，如果我们有N个slave,那是发N次，还是只发一次？如果只发一次，发给了slave-1，那slave-2,slave-3,…它们怎么办？
显然，应该发N次。实际上，在MySQL master内部，维护N个线程，每一个线程负责将二进制日志文件发往对应的slave。master既要负责写操作，还的维护N个线程，负担会很重。可以这样，slave-1是master的从，slave-1又是slave-2,slave-3,…的主，同时slave-1不再负责select。 slave-1将master的复制线程的负担，转移到自己的身上。这就是所谓的多级复制的概念。
6、当一个select发往MySQL proxy，可能这次由slave-2响应，下次由slave-3响应，这样的话，就无法利用查询缓存了。
应该找一个共享式的缓存，比如memcache来解决。将slave-2,slave-3,…这些查询的结果都缓存至mamcache中。
7、 随着应用的日益增长，读操作很多，我们可以扩展slave，但是如果master满足不了写操作了，怎么办呢？
scale on ?更好的服务器？ 没有最好的，只有更好的，太贵了。。。
scale out ? 主从复制架构已经满足不了。
可以分库【垂直拆分】，分表【水平拆分】。

3.mysql 高并发环境解决方案?

MySQL 高并发环境解决方案： 分库 分表 分布式 增加二级缓存

1. 需求分析：互联网单位 每天大量数据读取，写入，并发性高。
   现有解决方式：水平分库分表，由单点分布到多点数据库中，从而降低单点数据库压力。
2. 集群方案：解决DB宕机带来的单点DB不能访问问题。
3. 读写分离策略：极大限度提高了应用中Read数据的速度和并发量。无法解决高写入压力。

4.数据库崩溃时事务的恢复机制（REDO日志和UNDO日志）?

1. Undo Log:
   Undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用了Undo Log来实现多版本并发控制(简称：MVCC)。
   事务的原子性(Atomicity)事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。
   原理Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。
   之所以能同时保证原子性和持久化，是因为以下特点：
   更新数据前记录Undo log。
   为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
   Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的， 可以用来回滚事务。
   如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
   缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。
   如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log。
2. Redo Log:
   原理和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。