MySQL面试总结
标准SQL规范中定义的四个事务隔离级别
数据库操作面临的问题：脏读、不可重复读、幻读、更新丢失。
脏读
指一个事务读取了另一个事务未提交的记录。当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中；另外一个事务也访问这个数据，然后使用了这个未提交的数据。因为这个数据还没有提交，那么第二个事务读取到的是脏数据，依据脏数据所做的操作可能是不正确的。
不可重复读
指在一个事务内，多次重复执行某个查询，返回的记录不一致。例如：在一个事务还没有结束时，另外一个事务修改了该数据；在第一个事务中的两次读数据之间，由于第二个事务的修改，导致两次读取到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
幻读
指当事务不是独立执行时发生的一种现象，例如：第一个事务对表中的数据进行了批量修改（status=2）；同时第二个事务也修改这个表中的数据，向表中插入一行新数据（status=1），插入的数据刚好满足第一个事务的修改条件；操作第一个事务的用户发现表中还存在没有修改的数据行（status=1），就好象发生了幻觉一样。
更新丢失
两个事务都同时更新一行数据，一个事务对数据的更新把另一个事务对数据的更新覆盖了。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
对应的事物隔离级别
为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。
读未提交
读未提交（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
读已提交
读已提交（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
可重复读取（Repeatable Read）
可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻读数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
串行操作（Serializable）
串行化（Serializable）：提供严格的事务隔离。它要求事务串行化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
原文链接：
MySQL存储引擎MyISAM与InnoDB区别总结整理
1、MySQL默认存储引擎的变迁
在MySQL 5.1之前的版本中，默认的搜索引擎是MyISAM，从MySQL 5.5之后的版本中，默认的搜索引擎变更为InnoDB。
2、MyISAM与InnoDB存储引擎的主要特点
MyISAM存储引擎的特点是：表级锁、不支持事务和全文索引，适合一些CMS内容管理系统作为后台数据库使用，但是使用大并发、重负荷生产系统上，表锁结构的特性就显得力不从心；
InnoDB存储引擎的特点是：行级锁、事务安全（ACID兼容）、支持外键、不支持FULLTEXT类型的索引(5.6.4以后版本开始支持FULLTEXT类型的索引)。InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全存储引擎。InnoDB是为处理巨大量时拥有最大性能而设计的。它的CPU效率可能是任何其他基于磁盘的关系数据库引擎所不能匹敌的。
InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如
update table set num=1 where name like “a%”。
两种类型最主要的差别就是InnoDB支持事务处理与外键和行级锁。而MyISAM不支持。所以MyISAM往往就容易被人认为只适合在小项目中使用。
3、MyISAM与InnoDB性能测试
随着CPU核数的增加，InnoDB的吞吐量反而越好，而MyISAM，其吞吐量几乎没有什么变化，显然，MyISAM的表锁定机制降低了读和写的吞吐量。
4、事务支持与否
MyISAM是一种非事务性的引擎，使得MyISAM引擎的MySQL可以提供高速存储和检索，以及全文搜索能力，适合数据仓库等查询频繁的应用；
InnoDB是事务安全的；
事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而MyISAM就不可以了。
5、MyISAM与InnoDB构成上的区别
（1）每个MyISAM在磁盘上存储成三个文件：
第一个文件的名字以表的名字开始，扩展名指出文件类型，.frm文件存储表定义。
第二个文件是数据文件，其扩展名为.MYD (MYData)。
第三个文件是索引文件，其扩展名是.MYI (MYIndex)。
（2）基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的 大小只受限于操作系统文件的大小，一般为 2GB。
6、MyISAM与InnoDB表锁和行锁的解释
MySQL表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。什么意思呢，就是说对MyISAM表进行读操作时，它不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写操作；而对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作。
InnoDB行锁是通过给索引项加锁来实现的，即只有通过索引条件检索数据，InnoDB才使用行级锁，否则将使用表锁！行级锁在每次获取锁和释放锁的操作需要消耗比表锁更多的资源。在InnoDB两个事务发生死锁的时候，会计算出每个事务影响的行数，然后回滚行数少的那个事务。当锁定的场景中不涉及Innodb的时候，InnoDB是检测不到的。只能依靠锁定超时来解决。
7、是否保存数据库表中表的具体行数
InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table 时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。
注意的是，当count(*)语句包含where条件时，两种表的操作是一样的。也就是 上述“6”中介绍到的InnoDB使用表锁的一种情况。
8、如何选择
MyISAM适合：
（1）做很多count 的计算；
（2）插入不频繁，查询非常频繁，如果执行大量的SELECT，MyISAM是更好的选择；
（3）没有事务。
InnoDB适合：
（1）可靠性要求比较高，或者要求事务；
（2）表更新和查询都相当的频繁，并且表锁定的机会比较大的情况指定数据引擎的创建；
（3）如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表；
（4）DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的 删除；
（5）LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
要注意，创建每个表格的代码是相同的，除了最后的 TYPE参数，这一参数用来指定数据引擎。
其他区别：
1、对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
2、DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
3、LOAD TABLE FROMMASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。
4、 InnoDB存储引擎被完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。
5、对于自增长的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中可以和其他字段一起建立联合索引。
6、清空整个表时，InnoDB是一行一行的删除，效率非常慢。MyISAM则会重建表。
MYSQL数据库服务器性能分析的方法命令有哪些?
MySQL常用函数大全（总结篇）
唯一索引比普通索引快吗, 为什么？
唯一索引不一定比普通索引快, 还可能慢。
查询时, 在未使用limit 1的情况下, 在匹配到一条数据后, 唯一索引即返回, 普通索引会继续匹配下一条数据, 发现不匹配后返回. 如此看来唯一索引少了一次匹配, 但实际上这个消耗微乎其微.
更新时, 这个情况就比较复杂了. 普通索引将记录放到change buffer中语句就执行完毕了. 而对唯一索引而言, 它必须要校验唯一性, 因此, 必须将数据页读入内存确定没有冲突, 然后才能继续操作. 对于 写多读少的情况, 普通索引利用change buffer有效减少了对磁盘的访问次数, 因此普通索引性能要高于唯一索引.
MySQL由哪些部分组成, 分别用来做什么
Server
连接器: 管理连接, 权限验证.
分析器: 词法分析, 语法分析.
优化器: 执行计划生成, 索引的选择.
执行器: 操作存储引擎, 返回执行结果.
存储引擎: 存储数据, 提供读写接口.
MySQL怎么恢复半个月前的数据
通过整库备份+binlog进行恢复. 前提是要有定期整库备份且保存了binlog日志.
MySQL事务的隔离级别, 分别有什么特点
读未提交(RU): 一个事务还没提交时, 它做的变更就能被别的事务看到.
读提交(RC): 一个事务提交之后, 它做的变更才会被其他事务看到.
可重复读(RR): 一个事务执行过程中看到的数据, 总是跟这个事务在启动时看到的数据是一致的. 当然在可重复读隔离级别下, 未提交变更对其他事务也是不可见的.
串行化(S): 对于同一行记录, 读写都会加锁. 当出现读写锁冲突的时候, 后访问的事务必须等前一个事务执行完成才能继续执行.
MySQL索引详细介绍
MySQL中的索引的存储类型BTREE、HASH
做过哪些MySQL索引相关优化
尽量使用主键查询: 聚簇索引上存储了全部数据, 相比普通索引查询, 减少了回表的消耗.
MySQL5.6之后引入了索引下推优化, 通过适当的使用联合索引, 减少回表判断的消耗.
若频繁查询某一列数据, 可以考虑利用覆盖索引避免回表.
联合索引将高频字段放在最左边.
简要说一下数据库范式
点击查看
第一范式：字段的原子性：简单来说就是每一个字段不能分割出其他的属性
确保每列的原子性
如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元)，则满足第一范式.
例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。
第二范式：保证主键的唯一性，属性完全依赖于主键
在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关
如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。
第三范式：消除传递依赖，保证每个属性都直接依赖于主键
在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关
如果一个关系满足第二范式,并且除了主键以外的其它列都不依赖于主键列，则满足第三范式。
为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C， 如上所述，依赖A-〉C是传递依赖。
一千万条数据的表, 如何分页查询
数据量过大的情况下, limit offset分页会由于扫描数据太多而越往后查询越慢. 可以配合当前页最后一条ID进行查询, SELECT * FROM T WHERE id > #{ID} LIMIT #{LIMIT}. 当然, 这种情况下ID必须是有序的, 这也是有序ID的好处之一.
订单表数据量越来越大导致查询缓慢, 如何处理
分库分表. 由于历史订单使用率并不高, 高频的可能只是近期订单, 因此, 将订单表按照时间进行拆分, 根据数据量的大小考虑按月分表或按年分表. 订单ID最好包含时间(如根据雪花算法生成), 此时既能根据订单ID直接获取到订单记录, 也能按照时间进行查询。