1. 使用 mysql 索引都有哪些原则？
- 只对WHERE和ORDER BY需要查询的字段设置索引，避免无意义的硬盘开销；
- 组合索引支持前缀索引；
- 更新表的时候，如增删记录，MySQL会自动更新索引，保持树的平衡；因此更多的索引意味着更多的维护成本
索引分类
- index ----普通的索引,数据可以重复
- fulltext----全文索引，用来对大表的文本域(char，varchar，text)进行索引。语法和普通索引一样。
- unique ----唯一索引,唯一索引,要求所有记录都唯一
- primary key ----主键索引,也就是在唯一索引的基础上相应的列必须为主键
原则
- 单表数据太少，索引反而会影响速度；更新非常频繁的数据不适宜建索引
- where后的条件，order by ,group by 等这样过滤时，后面的字段最好加上索引。根据实际情况，选择PRIMARY KEY、UNIQUE、INDEX等索引，但是不是越多越好，要适度
- 联合查询，子查询等多表操作时关连字段要加索引
2. 索引什么数据结构？
MyISAM存储引擎文件有三个
- .frm 定义文件
- .MYD 数据文件
- .MYI 索引文件
InnoDB存储引擎文件有二个
- .frm表的定义文件
- .idb是数据文件
3. B+tree 和 B tree 什么区别？
MyISAM和InnoDB存储引擎简述
4. mysql 有哪些存储引擎啊？都有啥区别？
MyISAM和InnoDB存储引擎简述
5. 设计高并发系统数据库层面该怎么设计？
- 分表
比如秒杀场景，并发的任务都需要从数据库获取库存；单表数据库就会成为瓶颈：做法就是分表
把一个表的数据放到多个表中，然后查询的时候你就查一个表。
比如秒杀商品分到16个表中每次请求根据请求id进行hash之后取余，然后分到一个具体的表中更新当前的表；
比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。
- 分库
一个健康的单库并发值你最好保持在每秒 1000 左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。如果存在join可能需要中间件处理。
6. 数据库锁有哪些类型？如何实现？
从数据库系统角度分为三种：排他锁、共享锁、更新锁。
SELECT ... LOCK IN SHARE MODE;
SELECT ... FOR UPDATE;
从程序员角度分为两种：一种是悲观锁，一种乐观锁。
悲观锁
关系数据库里用到了很多这种锁机制，比如行锁、表锁、读锁、写锁等，都是在操作之前先上锁。
- 行锁
update … where id=?
这样的语句时，数据库明确知道会影响哪一行，它就会使用行锁；
- 表锁
update … where birthday=?
因为事先不知道会影响哪些行就可能会使用表锁。
SET LOCK_TIMEOUT 4000 用来设置锁等待时间，单位是毫秒，4000意味着等待
4秒可以用select @@LOCK_TIMEOUT查看当前session的锁超时设置。-1 意味着
永远等待。
乐观锁
- 版本号
就是给数据增加一个版本标识，在数据库上就是表中增加一个version字段，每次更新把这个字段加1，读取数据的时候把version读出来，更新的时候比较version，如果还是开始读取的version就可以更新了，如果现在的version比老的version大，说明有其他事务更新了该数据，并增加了版本号，这时候得到一个无法更新的通知，用户自行根据这个通知来决定怎么处理，比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行，否则在你判断可以更新以后正式更新之前有别的事务修改了version，这个时候你再去更新就可能会覆盖前一个事务做的更新，造成第二类丢失更新，所以你可以使用update … where … and version=”old version”这样的语句，根据返回结果是0还是非0来得到通知，如果是0说明更新没有成功，因为version被改了，如果返回非0说明更新成功。
7.数据库常用的事务隔离级别都有哪些？都是什么原理？
具备四个特性，分别是：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)，也就是我们常说的事务ACID，这样才能保证事务((Transaction)中数据的正确性。
- 隔离级别
读未提交(Read Uncommitted)
可能会产生“脏读”、“不可重复读”、“幻读”-
读提交(Read Committed)
select * from T where ID=2 lock in share mode; select * from T where ID=2 for update;不然，普通的查询是不会加锁的。
为什么“读提交”同“读未提交”一样，都没有查询加锁，但是却能够避免脏读呢?
“快照(snapshot)”，而这种既能保证一致性又不加锁的读也被称为“快照读(Snapshot Read)”
假设没有“快照读”，那么当一个更新的事务没有提交时，另一个对更新数据进行查询的事务会因为无法查询而被阻塞，这种情况下，并发能力就相当的差。而“快照读”就可以完成高并发的查询，不过，“读提交”只能避免“脏读”，并不能避免“不可重复读”和“幻读”。 可重复读(Repeated Read)
可重复读，顾名思义，就是专门针对“不可重复读”这种情况而制定的隔离级别，自然，它就可以有效的避免“不可重复读”。而它也是MySql的默认隔离级别。在这个级别下，普通的查询同样是使用的“快照读”，但是，和“读提交”不同的是，当事务启动时，就不允许进行“修改操作(Update)”了，而“不可重复读”恰恰是因为两次读取之间进行了数据的修改，因此，“可重复读”能够有效的避免“不可重复读”，但却避免不了“幻读”，因为幻读是由于“插入或者删除操作(Insert or Delete)”而产生的。串行化(Serializable)
这是数据库的隔离级别，这种级别下，事务“串行化顺序执行”，也就是一个一个排队执行。这种级别下，“脏读”、“不可重复读”、“幻读”都可以被避免，但是执行效率奇差，性能开销也，所以基本没人会用。
8.如何设计可以动态扩容缩容的分库分表方案？
- 停机扩容
停机迁移，然后重启 - 基于日志追平
写入的时候同时写入两份；保存日志；校验新库并且在校验之后，根据旧库这段时间的日志追平新库，短时间停机即可
9.分库分表中间件，有啥优点和缺点，分库分表中间件的底层实现原理？
分布式事务问题
如果我们做了垂直分库或者水平分库以后,就必然会涉及到跨库执行SQL的问题,这样就引发了互联网界的老大难问题-"分布式事务"。那要如何解决这个问题呢？
1.使用分布式事务中间件 2.使用MySQL自带的针对跨库的事务一致性方案(XA),不过性能要比单库的慢10倍左右。3.能否避免掉跨库操作(比如将用户和商品放在同一个库中)跨库join的问题
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。横向扩容的问题
当我们使用HASH取模做分表的时候,针对数据量的递增,可能需要动态的增加表,此时就需要考虑因为reHash导致数据迁移的问题。结果集合并、排序的问题
因为我们是将数据分散存储到不同的库、表里的,当我们查询指定数据列表时,数据来源于不同的子库或者子表,就必然会引发结果集合并、排序的问题。如果每次查询都需要排序、合并等操作,性能肯定会受非常大的影响。走缓存可能一条路!
拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
10. 分布式事务怎么解决的？ TCC？那若出现网络原因，网络连不通怎么办？
大规模SOA系统中的分布事务处事_程立
TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。
Try：预留业务资源/数据效验
Confirm：确认执行业务操作
Cancel：取消执行业务操作
TCC 优缺点
TCC优点：让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
TCC不足之处：
对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。
我们通过用户下单使用余额+红包支付来看一下TCC事务的具体应用。
假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统，下单成功需要同时调用资金账户服务和红包服务完成支付
假设购买商品1000元，使用账户红包200元，余额800元，确认支付。
Try操作
tryX 下单系统创建待支付订单
tryY 冻结账户红包200元
tryZ 冻结资金账户800元
Confirm操作
confirmX 订单更新为支付成功
confirmY 扣减账户红包200元
confirmZ 扣减资金账户800元
Cancel操作
cancelX 订单处理异常，资金红包退回，订单支付失败
cancelY 冻结红包失败，账户余额退回，订单支付失败
cancelZ 冻结余额失败，账户红包退回，订单支付失败
11.分布式寻址方式都有哪些算法？一致性hash
分布式均匀算法
hash 算法（大量缓存重建）
首先计算key的 hash 值，然后对节点数取模。然后打在不同的 master 节点上。一旦某一个 master 节点宕机，所有请求过来，都会基于最新的剩余 master 节点数去取模，尝试去取数据。这会导致大部分的请求过来，全部无法拿到有效的缓存，导致大量的流量涌入数据库。-
一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
一致性 hash 算法将整个 hash 值空间组织成一个虚拟的圆环，整个空间按顺时针方向组织，下一步将各个 master 节点（使用服务器的 ip 或主机名）进行 hash。这样就能确定每个节点在其哈希环上的位置。来了一个 key，首先计算 hash 值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，遇到的第一个 master 节点就是 key 所在位置。
在一致性哈希算法中，如果一个节点挂了，受影响的数据仅仅是此节点到环空间前一个节点（沿着逆时针方向行走遇到的第一个节点）之间的数据，其它不受影响。增加一个节点也同理。
image -
redis cluster 的 hash slot 算法
redis cluster 有固定的 16384 个 hash slot，对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。每个节点负责维护一部分槽以及槽所映射的键值数据。
redis cluster 中每个 master 都会持有部分 slot，比如有 3 个 master，那么可能每个 master 持有 5000 多个 hash slot。hash slot 让 node 的增加和移除很简单，增加一个 master，就将其他 master 的 hash slot 移动部分过去，减少一个 master，就将它的 hash slot 移动到其他 master 上去。移动 hash slot 的成本是非常低的。客户端的 api，可以对指定的数据，让他们走同一个 hash slot，通过 hash tag 来实现。
[图片上传中...(image-f10d63-1576742673973)]
image
一致性hash的golang实现 这种实现不是简单的分段，增加了replica的设置，将每个节点的槽位打散；比如可能是0-100 node1 100-200node2 200-300node3，300-400node2，400-500node1，500-600node3；原算法在remove一个node之后，影响的是后面的节点，那么后面的节点压力就会变大；改进之后理论上所有的节点平分了这个压力。
如何解决分库分表主键问题？有什么实现方案？
- Twitter的Snowflake（又名“雪花算法”）
- UUID/GUID（一般应用程序和数据库均支持）
- MongoDB ObjectID（类似UUID的方式）
- Ticket Server（数据库生存方式，Flickr采用的就是这种方式）
11. 跨分片技术问题
跨分片的排序分页
[图片上传失败...(image-863348-1576743217496)]
当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。
上面图中所描述的只是最简单的一种情况（取第一页数据），看起来对性能的影响并不大。但是，如果想取出第10页数据，情况又将变得复杂很多，如下图所示：
有些读者可能并不太理解，为什么不能像获取第一页数据那样简单处理（排序取出前10条再合并、排序）。其实并不难理解，因为各分片节点中的数据可能是随机的，为了排序的准确性，必须把所有分片节点的前N页数据都排序好后做合并，最后再进行整体的排序。很显然，这样的操作是比较消耗资源的，用户越往后翻页，系统性能将会越差。
跨分片的函数处理
在使用Max、Min、Sum、Count之类的函数进行统计和计算的时候，需要先在每个分片数据源上执行相应的函数处理，然后再将各个结果集进行二次处理，最终再将处理结果返回。如下图所示：
跨分片join
Join是关系型数据库中最常用的特性，但是在分片集群中，join也变得非常复杂。应该尽量避免跨分片的join查询（这种场景，比上面的跨分片分页更加复杂，而且对性能的影响很大）。通常有以下几种方式来避免：
全局表
全局表的概念之前在“垂直分库”时提过。基本思想一致，就是把一些类似数据字典又可能会产生join查询的表信息放到各分片中，从而避免跨分片的join。
ER分片
在关系型数据库中，表之间往往存在一些关联的关系。如果我们可以先确定好关联关系，并将那些存在关联关系的表记录存放在同一个分片上，那么就能很好的避免跨分片join问题。在一对多关系的情况下，我们通常会选择按照数据较多的那一方进行拆分。如下图所示：
这样一来，Data Node1上面的订单表与订单详细表就可以直接关联，进行局部的join查询了，Data Node2上也一样。基于ER分片的这种方式，能够有效避免大多数业务场景中的跨分片join问题。
内存计算
随着spark内存计算的兴起，理论上来讲，很多跨数据源的操作问题看起来似乎都能够得到解决。可以将数据丢给spark集群进行内存计算，最后将计算结果返回。
跨分片事务问题
跨分片事务也分布式事务，想要了解分布式事务，就需要了解“XA接口”和“两阶段提交”。值得提到的是，MySQL5.5x和5.6x中的xa支持是存在问题的，会导致主从数据不一致。直到5.7x版本中才得到修复。Java应用程序可以采用Atomikos框架来实现XA事务（J2EE中JTA）。感兴趣的读者可以自行参考《分布式事务一致性解决方案》，链接地址：
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency