1、什么是数据库事务？

「数据库事务」: 是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。

2、事务的四大特性是什么？

• 「原子性」：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
• 「一致性」：指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
• 「隔离性」：多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。
• 「持久性」：表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。

3、事务ACID特性的实现原理？

• 「原子性」：是使用 undo log 来实现的，如果事务执行过程中出错或者用户执行了rollback，系统通过undo log日志返回事务开始的状态。
• 「持久性」：使用 redo log来实现，只要redo log日志持久化了，当系统崩溃，即可通过redo log把数据恢复。
• 「隔离性」：通过锁以及 MVCC,使事务相互隔离开。
• 「一致性」：通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。

有关MVCC相关知识可以参考:看一遍就懂：MVCC原理详解

4、事务的隔离级别有哪些？

• 「读未提交」（Read Uncommitted）最低级别，任何情况都无法保证
• 「读已提交」（Read Committed）可避免脏读的发生
• 「可重复读」（Repeatable Read）可避免脏读、不可重复读的发生
• 「串行化」（Serializable）可避免脏读、不可重复读、幻读的发生

Mysql默认的事务隔离级别是「可重复读」(Repeatable Read)

5、什么是脏读、不可重复读、幻读呢？

• 「脏读」: 脏读指的是读到了其他事务未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不会存到数据库中，也就是不存在的数据。读到了并不一定最终存在的数据，这就是脏读。
• 「不可重复读」: 不可重复读指的是在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据出现不一致的情况。
• 「幻读」: 幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。

具体看之前写的一篇文章一文详解脏读、不可重复读、幻读

6、datetime和timestamp的区别？

它们和date的区别在于: date存储精度到天，它们存储精度都为秒。

它们的区别在于：

• datetime 的日期范围是 1001——9999 年；timestamp 的时间范围是 1970——2038 年
• datetime 存储时间与时区无关；timestamp 存储时间与时区有关，显示的值也依赖于时区
• datetime 的存储空间为 8 字节；timestamp 的存储空间为 4 字节
• datetime 的默认值为 null；timestamp 的字段默认不为空(not null)，默认值为当前时间(current_timestamp)

7、varchar和char有什么区别？

char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容.该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。

在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar.例如存储用户MD5加密后的密码,则应该使用char。

8、count(1)、count(*) 与 count(列名) 的区别？

• count()*包括了所有的列，相当于行数，在统计结果的时候，不会忽略列值为NULL
• count(1)包括了忽略所有列，用1代表代码行，在统计结果的时候，不会忽略列值为NULL
• count(列名)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空表示null）的计数，即某个字段值为NULL时，不统计。

阿里巴巴Java开发手册有一条强制建议：不要使用count(列名)或count(常量)来代替count()。count()就是SQL92定义的标准统计行数语法，跟数据库无关。

9、exist和in的区别？

  -- in  select * from a where id in (select id from b);  -- exists select * from A where exists(select 1 from B where B.id = A.id);

使用in时,sql语句是先执行子查询，也就是先查询子表b，再查主表a。而使用exists是先查主表a ,再查询子表b。

根据小表驱动大表(即小的数据集驱动大的数据集)的原则,如果主查询中的表较大且又有索引时应该用in。反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。

还有一点注意的是用 exists 该子查询实际上并不返回任何数据，而是返回值True或False。

「not in 和not exists」

如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。

10、truncate、delete与drop区别？

delete truncate drop类型DML DDL DDL回滚可回滚不可回滚不可回滚删除内容表结构还在，删除表的全部或者一部分数据行表结构还在，删除表中的所有数据表结构也会删除，所有的数据行，索引和权限也会被删除删除速度删除速度慢，逐行删除删除速度快删除速度最快

11、union与union all的区别？

• Union：对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
• Union All：对两个结果集进行并集操作，包括重复行，不进行排序；
• 从效率上说，union all 要比union快很多，所以，如果可以确认合并的两个结果集中不包含重复的数据的话，那么就使用union all

12、group by 和 distinct 的区别？

它们本质语言逻辑上的数据处理动作先后是不一样，distinct 是先获取结果集，再去重复记录。group by 是基于KEY先分组，再返回计算结果。

从效率上来讲 group by和distinct都能使用索引,在相同语义下，从执行效率上也看不到明显的差异;

那为什么，大家都更推崇使用group by？

• group by语义更为清晰，灵活
• group by可对数据进行更为复杂的一些处理

由于distinct关键字会对所有字段生效，在进行复合业务处理时，group by的使用灵活性更高，group by能根据分组情况，对数据进行更为复杂的处理，例如通过having对数据进行过滤，或通过聚合函数对数据进行运算。

13、Blob和text有什么区别？

• Blob用于存储二进制数据，而Text用于存储大字符串。
• Blob值被视为二进制字符串（字节字符串）,它们没有字符集，并且排序和比较基于列值中的字节的数值。
• text值被视为非二进制字符串（字符字符串）。它们有一个字符集，并根据字符集的排序规则对值进行排序和比较。

14、常见的存储引擎有哪些？

Mysql中常用的四种存储引擎分别是：MyISAM、InnoDB、MEMORY、ARCHIVE。Mysql 5.5版本后默认的存储引擎为InnoDB。

15、说一说InnoDB与MyISAM的区别？

MyISAM和InnoDB两者之间还是有着明显区别

1. 「事务支持」

MyISAM不支持事务，而InnoDB支持。

2. 「表锁差异」

MyISAM：只支持表级锁。

InnoDB：支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁,只有在索引上才可能是行锁，否则还是表锁。

3）「索引结构」

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址，即：MyISAM索引文件和数据文件是分离的，MyISAM的索引文件仅仅保存数据记录的地址。MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。MyISAM的索引方式也叫做“非聚集”的。

InnoDB引擎也使用B+Tree作为索引结构，但是InnoDB的数据文件本身就是索引文件，叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这种索引叫做“聚焦索引”。InnoDB的辅助索引的data域存储相应记录主键的值而不是地址。

4）「表主键」

MyISAM：允许没有任何索引和主键的表存在，索引都是保存行的地址。

InnoDB：如果没有设定主键或者非空唯一索引，就会自动生成一个6字节的主键(用户不可见)，数据是主索引的一部分，其它索引保存的是主索引的值。

5. 「表的具体行数」

MyISAM：保存有表的总行数，如果select count(*) from table;会直接取出出该值。

InnoDB：没有保存表的总行数(只能遍历)，如果使用select count(*) from table；就会遍历整个表，消耗相当大，但是在加了where条件后，myisam和innodb处理的方式都一样。

6. 「外键」

MyISAM：不支持

InnoDB：支持

16、bin log/redo log/undo log是什么？

bin log、redo log、undo log三种日志属于不同级别的日志，按照Mysql的划分可以分为服务层和引擎层两大层，bin log是在服务层实现的；redo log、undo log是在引擎层实现的，且是innodb引擎独有的，主要和事务相关。

「1、bin log」

bin log是Mysql数据库级别的文件，记录对Mysql数据库执行修改的所有操作，不会记录select和show语句。使用任何存储引擎的 Mysql 数据库都会记录 binlog 日志。

在实际应用中， binlog 的主要使用场景有两个，分别是 主从复制 和 数据恢复 。

主从复制 ：在 Master 端开启 binlog ，然后将 binlog发送到各个 Slave 端， 从而达到主从数据一致。

数据恢复 ：通过使用 Mysqlbinlog 工具来恢复数据。

「2、redo log」

redo log中记录的是要更新的数据，比如一条数据已提交成功，并不会立即同步到磁盘，而是先记录到redo log中，等待合适的时机再刷盘，为了实现事务的持久性。

如果没有redo log,那么每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

因为 Innodb 是以 页 为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！

一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

因此 Mysql 设计了 redo log ， 具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

「3、undo log」

除了记录redo log外，当进行数据修改时还会记录undo log，undo log用于数据的撤回操作，它保留了记录修改前的内容。通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC。

17、bin log和redo log有什么区别？

• bin log会记录所有日志记录，包括InnoDB、MyISAM等存储引擎的日志；redo log只记录innoDB自身的事务日志。
• bin log只在事务提交前写入到磁盘，一个事务只写一次；而在事务进行过程，会有redo log不断写入磁盘。
• bin log是逻辑日志，记录的是SQL语句的原始逻辑；redo log是物理日志，记录的是在某个数据页上做了什么修改。

18、说一下数据库的三大范式？

• 第一范式：数据表中的每一列（每个字段）都不可以再拆分。
• 第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。
• 第三范式：在满足第二范式的基础上，表中的非主键只依赖于主键，而不依赖于其他非主键。

19、什么是存储过程？有哪些优缺点？

「存储过程」，就是一些编译好了的SQL语句，这些SQL语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后给这些代码块取一个名字，在用到这个功能的时候调用即可。

「优点：」

• 存储过程是一个预编译的代码块，执行效率比较高
• 存储过程在服务器端运行，减少客户端的压力
• 允许模块化程序设计，只需要创建一次过程，以后在程序中就可以调用该过程任意次，类似方法的复用
• 一个存储过程替代大量SQL语句 ，可以降低网络通信量，提高通信速率
• 可以一定程度上确保数据安全

「缺点：」

• 调试麻烦
• 可移植性不灵活
• 重新编译问题

20、主键使用自增ID还是UUID?

推荐使用自增ID,不要使用UUID。

因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。

21、超大分页怎么处理?

• 「用id优化」

先找到上次分页的最大ID,然后利用id上的索引来查询,类似于

 select * from user where id>1000000 limit 100

这样的效率非常快,因为主键上是有索引的,但是这样有个缺点,就是ID必须是连续的,并且查询不能有where语句,因为where语句会造成过滤数据。

• 「用覆盖索引优化」

Mysql的查询完全命中索引的时候,称为覆盖索引,是非常快的,因为查询只需要在索引上进行查找,之后可以直接返回,而不用再回表拿数据.因此我们可以先查出索引的ID,然后根据Id拿数据.

 select * from table where id in (select id from table where age > 20 limit 1000000,10)

• 「在业务允许的情况下限制页数」

建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。

22、一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。

这是一道腾讯的面试题，其实这个问题和上面是同一个问题，都是超大分页的问题,这就像读书的时候做数学题一样，上面是公式、定理，下面是题目，所以要学会举一反三。

1、如果A表TID是自增长,并且是连续的,B表的ID为索引

select * from a,b where a.tid = b.id and a.tid>500000 limit 200;

2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。

select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;

23、日常开发中你是怎么优化SQL的？

这个问题问的挺大的，那么我们可以也先从几个大的纬度来回答。

1. 添加合适索引
2. 优化表结构
3. 优化查询语句

然后针对每个大的纬度稍微讲几句。

「1、添加合适索引」

• 对作为查询条件和order by的字段建立索引。
• 对于多个查询字段的考虑建立组合索引，同时注意组合索引字段的顺序,将最常用作限制条件的列放在最左边，依次递减。
• 索引不宜太多，一般5个以内。

「2、优化表结构」

选择正确的数据类型，对于提高性能也是至关重要。下面给出几种原则:

• 「数字型字段优于字符串类型」若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
• 「数据类型更小通常更好」使用最小的数据类型,会减少磁盘的空间，内存和CPU缓存。好比时间类型尽量使用TIMESTAMP类型，因为其存储空间只需要 DATETIME 类型的一半。对于只需要精确到某一天的数据类型，建议使用DATE类型，因为他的存储空间只需要3个字节，比TIMESTAMP还少。
• 「尽量使用 NOT NULL」NULL 类型比较特殊，SQL 难优化。如果是一个组合索引，那么这个NULL 类型的字段会极大影响整个索引的效率。此外，NULL 在索引中的处理也是特殊的，也会占用额外的存放空间。

「3、优化查询语句」

• 分析语句，是否加载了不必要的字段/数据。
• 分析SQl执行计划，是否命中索引等。
• 如果SQL很复杂，优化SQL结构
• 如果表数据量太大，考虑分表

24、关心过业务系统里面的sql耗时吗?统计过慢查询吗?对慢查询都怎么优化过?（explain）？

在业务系统中,除了使用主键进行的查询,其他的我都会在测试库上测试其耗时,慢查询的统计主要由运维在做,会定期将业务中的慢查询反馈给我们。

慢查询的优化首先要搞明白慢的原因是什么? 是查询条件没有命中索引?是load了不需要的数据列?还是数据量太大?

所以优化也是针对这三个方向来的,

• 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。
• 分析语句的执行计划(explain),然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。
• 如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。

25、一条sql执行过长的时间，你如何优化，从哪些方面入手？

• 查看是否涉及多表和子查询，优化Sql结构，如去除冗余字段，是否可拆表等
• 优化索引结构，看是否可以适当添加索引
• 数量大的表，可以考虑进行分离/分表（如交易流水表）
• 数据库主从分离，读写分离
• explain分析sql语句，查看执行计划，优化sql
• 查看Mysql执行日志，分析是否有其他方面的问题

上面这3道面试题也是差不多的，只是问的方式不一样，可以总结出自己的话术来表达。

26、产生临时表的原因有哪些？

你在对sql分析语句的执行计划(explain)的时候，发现「extra」中有Using temporary,那就说明使用了临时表保存中间结果，Mysql在对查询结果排序时使用临时表。出现这种情况我们就需要看下能不能优化一下了。

那首先知道什么情况下会产生临时表

1）order by子句和group by子句不同， 例如：ordery by price group by name；

2）order by中使用了distinct关键字 ordery by distinct(price)

3）直接使用磁盘临时表的场景

• 表包含text或者blob列；
• group by 或者 distinct 子句中包含长度大于512字节的列；
• 使用union或者union all时，select子句中包含大于512字节的列；

27、如何解决临时表问题呢？

使用临时表一般都意味着性能比较低，特别是使用磁盘临时表，性能更慢，因此我们在实际应用中应该尽量避免临时表的使用。常见的避免临时表的方法有：

• 创建索引：在ORDER BY或者GROUP BY的列上创建索引；
• 如果你的varvhar2，字节数是否超过512字节，看能否修改。
• 分拆很长的列：一般情况下，TEXT、BLOB，大于512字节的字符串，基本上都是为了显示信息，而不会用于查询条件， 因此表设计的时候，应该将这些列独立到另外一张表。

28、如何选择合适的分布式主键方案呢？

• 数据库自增长序列或字段。
• UUID。
• Redis生成ID
• Twitter的snowflake算法
• 利用zookeeper生成唯一ID
• MongoDB的ObjectId

29、说一下大表查询的优化方案

• 优化shema、sql语句+索引；
• 可以考虑加缓存，memcached, redis，或者JVM本地缓存；
• 主从复制，读写分离；
• 分库分表；

30、百万级别或以上的数据，你是如何删除的？

• 我们想要删除百万数据的时候可以先删除索引
• 然后批量删除其中无用数据
• 删除完成后重新创建索引。

31、为什么要分库分表？

「分表」

比如你单表都几千万数据了，你确定你能扛住么？绝对不行，单表数据量太大，会极大影响你的 sql 执行的性能，到了后面你的 sql 可能就跑的很慢了。一般来说，就以我的经验来看，单表到几百万的时候，性能就会相对差一些了，你就得分表了。

分表是啥意思？就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。

「分库」

分库是啥意思？就是你一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。

32、说说分库与分表的设计？

「分库分表方案:」

• 水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
• 水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
• 垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
• 垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

具体可以参考之前写的一篇文章: 分库分表(1) --- 理论 https://www.cnblogs.com/qdhxhz/p/11608222.html

33、分库分表数据分片规则？

我们在考虑去水平切分表，将一张表水平切分成多张表，这就涉及到数据分片的规则，比较常见的有：Hash取模分表、数值Range分表、一致性Hash算法分表。

1)、「Hash取模分表」

概念 一般采用Hash取模的切分方式，例如：假设按goods_id分4张表。（goods_id%4 取整确定表）

「优点」

• 数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈。

「缺点」

• 后期分片集群扩容时，需要迁移旧的数据很难。
• 容易面临跨分片查询的复杂问题。比如上例中，如果频繁用到的查询条件中不带goods_id时,将会导致无法定位数据库,从而需要同时向4个库发起查询， 再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。

「2)、数值Range分表」

概念 按照时间区间或ID区间来切分。例如：将goods_id为11000的记录分到第一个表，10012000的分到第二个表，以此类推。

「优点」

• 单表大小可控
• 天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移
• 使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。

「缺点」

• 热点数据成为性能瓶颈。例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询

「3)、一致性Hash算法」

一致性Hash算法能很好的解决因为Hash取模而产生的分片集群扩容时，需要迁移旧的数据的难题。至于具体原理这里就不详细说。

34、分库分表带来的问题有哪些？

「1、分布式事务问题」

使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求，这里就不多说。

「2、跨节点关联查询 Join 问题」

切分之前，我们可以通过Join来完成。而切分之后，数据可能分布在不同的节点上，此时Join带来的问题就比较麻烦了，考虑到性能，尽量避免使用Join查询。

解决这个问题的一些方法：

全局表

全局表，也可看做是 "数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库Join查询，可以将 这类表在每个数据库中都保存一份。这些数据通常 很少会进行修改，所以也不担心一致性的问题。

字段冗余

利用空间换时间，为了性能而避免join查询。例：订单表保存userId时候,也将userName冗余保存一份，这样查询订单详情时就不需要再去查询"买家user表"了。

数据组装

在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。

「3、跨节点分页、排序、函数问题」

跨节点多库进行查询时，会出现Limit分页、Order by排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；

当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。

「4、全局主键避重问题」

如果都用主键自增肯定不合理，如果用UUID那么无法做到根据主键排序，所以我们可以考虑通过雪花ID来作为数据库的主键，

「5、数据迁移问题」

采用双写的方式，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写， 边写边按时间比较数据是不是最新的。

35、sharding-jdbc 和 mycat比较？

sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖；

mycat 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。

36、现在有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？

「1）停机迁移方案」

我先给你说一个最 low 的方案，就是很简单，大家伙儿凌晨 12 点开始运维，网站或者 app 挂个公告，说 0 点到早上 6 点进行运维，无法访问。

接着到 0 点停机，系统停掉，没有流量写入了，此时老的单库单表数据库静止了。然后你之前得写好一个导数的一次性工具，此时直接跑起来，然后将单库单表的数据哗哗哗读出来，写到分库分表里面去。

导数完了之后，就 ok 了，修改系统的数据库连接配置啥的，包括可能代码和 SQL 也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。

验证一下，ok了，完美，大家伸个懒腰，看看看凌晨 4 点钟的北京夜景，打个滴滴回家吧。

但是这个方案比较 low，谁都能干，我们来看看高大上一点的方案。

「2）双写迁移方案」

这个是我们常用的一种迁移方案，比较靠谱一些，不用停机，不用看北京凌晨 4 点的风景。

简单来说，就是在线上系统里面，之前所有写库的地方，增删改操作，除了对老库增删改，都加上对新库的增删改，这就是所谓的双写，同时写俩库，老库和新库。

然后系统部署之后，新库数据差太远，用之前说的导数工具，跑起来读老库数据写新库，写的时候要根据 gmt_modified 这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。简单来说，就是不允许用老数据覆盖新数据。

导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。

接着当数据完全一致了，就 ok 了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩儿数据迁移之类的，都是这么干的。

37、如何设计可以动态扩容缩容的分库分表方案？

「1）停机扩容（不推荐）」

这个方案就跟停机迁移一样，步骤几乎一致，唯一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿，有点不太靠谱，因为既然分库分表就说明数据量实在是太大了，可能多达几亿条，甚至几十亿，你这么玩儿，可能会出问题。

从单库单表迁移到分库分表的时候，数据量并不是很大，单表最大也就两三千万。那么你写个工具，多弄几台机器并行跑，1小时数据就导完了。这没有问题。

如果 3 个库 + 12 个表，跑了一段时间了，数据量都 1~2 亿了。光是导 2 亿数据，都要导个几个小时，6 点，刚刚导完数据，还要搞后续的修改配置，重启系统，测试验证，10 点才可以搞完。所以不能这么搞。

「2）优化后的方案」

一开始上来就是 32 个库，每个库 32 个表，那么总共是 1024 张表。

我可以告诉各位同学，这个分法，第一，基本上国内的互联网肯定都是够用了，第二，无论是并发支撑还是数据量支撑都没问题。

每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5万/s 的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。

有些除非是国内排名非常靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库的这么一个规模，128个库，256个库，512个库。

1024 张表，假设每个表放 500 万数据，在 Mysql 里可以放 50 亿条数据。

每秒的 5 万写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。

谈分库分表的扩容，第一次分库分表，就一次性给他分个够，32 个库，1024 张表，可能对大部分的中小型互联网公司来说，已经可以支撑好几年了。

一个实践是利用 32 * 32 来分库分表，即分为 32 个库，每个库里一个表分为 32 张表。一共就是 1024 张表。根据某个 id 先根据 32 取模路由到库，再根据 32 取模路由到库里的表。

38、Mysql 主从复制原理的是啥？

这里先放一张图，这张图很好的诠释的主从复制的原理

[图片上传失败...(image-e0b92a-1659073610080)]

上面主要分成了三步，下面会详细说明。

(1) Master的更新事件(update、insert、delete)会按照顺序写入bin-log中。当Slave连接到Master的后,Master机器会为Slave开启

binlog dump线程,该线程会去读取bin-log日志

(2) Slave连接到Master后,Slave库有一个I/O线程 通过请求binlog dump thread读取bin-log日志,然后写入从库的relay log日志中。

(3) Slave还有一个 SQL线程,实时监控 relay-log日志内容是否有更新,解析文件中的SQL语句,在Slave数据库中去执行。

总结

(1) 既然是要把事件记录到bin-log日志，那么对于Master就必须开启bin-log功能。

(2) 整个Mysql主从复制一共开启了3个线程。Master开启 IO线程，Slave开启 IO线程 和 SQL线程。

(3) 这点也很重要那就是Master和Slave交互的时候，记住这里是Slave去请求Master,而不是Master主动推给Slave。Slave通过IO线程

连接Master后发起请求,Master服务器收到Slave IO线程发来的日志请求信息，io线程去将bin-log内容返回给slave IO线程。

39、Mysql主从复制同步方式有哪些？

(1) 异步复制

Mysql主从同步 默认是异步复制的。就是上面三步中,只有第一步是同步的(也就是Mater写入bin log日志),就是主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程。

Master 不关心 Slave 的数据有没有写入成功。因此如果Master和Slave之间有网络延迟，就会造成暂时的数据不一致的现象；

如果Master出故障，而数据还没有复制过去，则会造成数据丢失；但也有好处，效率较其他两种复制方式最高。

(2) 同步复制

对于同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到所有Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。

这种复制方式最安全，但是同时，效率也是最差的。

(3) 半同步复制

对于半同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到其中一个Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。

由此增强了数据的一致性，但是因为Master主机的确认开销，会损耗一部分的性能；

另外，半同步复制除了不需要等待所有Slave主机确认事件的接收外，半同步数据复制并不要求那些事件完全地执行，因此，仍有可能看到在Slave主机上数据复制延迟的发生，如果因为网络延迟等原因造成Slave迟迟没有返回复制成功的信息，超过了Master设置的超时时长，半同步复制就降级为异步复制方式，而后继续数据复制。

40、Mysql主从同步延时产生原因?怎么优化？

上面也说了，「Mysql默认采用的异步操作」，因为它的效率明显是最高的。因为只要写入bin log后事物就结束返回成功了。但由于从库从主库异步拷贝日志 以及 串行执行 SQL 的特点，所以从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。这就是主从同步延时问题。

「1)、影响延迟因素」

这里整理了影响主从复制延迟大致有以下几个原因：

• 主节点如果执行一个很大的事务，那么就会对主从延迟产生较大的影响
• 网络延迟，日志较大，slave数量过多
• 主上多线程写入，从节点只有单线程同步
• 机器性能问题，从节点是否使用了“烂机器”
• 锁冲突问题也可能导致从机的SQL线程执行慢

「2）、优化主从复制延迟」

这个没有说去完全解决，要想解决那么就只能采用同步复制策略。不过，一般不建议使用这种同步模式。显而易见，如果写操作必须等待更新同步完成，肯定会极大地影响性能，除非你不在乎性能。

1）大事务：将大事务分为小事务，分批更新数据

2）减少Slave的数量，不要超过5个，减少单次事务的大小

3）Mysql 5.7之后，可以使用多线程复制，使用MGR复制架构

4）在磁盘、raid卡、调度策略有问题的情况下可能会出现单个IO延迟很高的情况，可用iostat命令查看DB数据盘的IO情况，再进一步判断

5）针对锁问题可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看

总结

主机与从机之间的物理延迟是无法避免的，既然无法避免就可以考虑尝试通过缓存等方式，降低新修改数据被立即读取的概率。