目录
15.分表后非分库字段sharding_key的查询怎么处理呢？
11.那你知道什么是覆盖索引和回表吗？
覆盖索引指的是在一次查询中，如果一个索引包含或者说覆盖所有需要查询的字段的值，我们就称之为覆盖索引，而不再需要回表查询。
而要确定一个查询是否是覆盖索引，我们只需要explain SQL语句看Extra的结果是否是"Using index"即可。
比如：
explain select * from user where age=1;
explain select id,age from user where age=1;
12.什么是MVCC？说说MySQL实现MVCC的原理？
什么是MVCC？
MVCC，全称Multi-Version Concurrency Control,即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。在Mysql的Innodb引擎中就是指在已提交读(read committed)和可重复读（repeatable read)这两种隔离级别下的事务对于SELECT操作会访问版本链中的记录的过程。这就使得别的事务可以修改这条记录，反正每次修改都会在版本链中记录。SELECT可以去版本链中拿记录，这就实现了读-写，写-读的并发执行，提升了系统的性能。
MySQL的innodb引擎实现MVCC的3个基础点
1.隐式字段
2.undo log
不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，即链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录。
3.readview
已提交读和可重复读的区别就在于它们生成readview的策略不同。
readview中主要就是有个列表来存储我们系统中当前活跃着的读写事务，也就是begin了还未提交的事务。通过这个列表来判断记录的某个版本是否对当前事务可见。假设当前列表里面的事务id为[80,100]。
1)如果你要访问的记录版本的事务id为50，比当前列表最小的id 80小，那说明这个事务在之前就提交了，所以对当前活动的事务来说是可访问的。
2）如果你要访问的记录版本的事务id为90，发现此事务在列表id最大值和最小值之间，那就再判断一下是否在列表内，如果在那就说明此事务还未提交，所以此版本不能被访问。如果不再那说明此事务已经提交，所以版本可以被访问。
3）如果你要访问的记录版本的事务id为110，那比事务列表最大的id 100都大，那说明这个版本是在readview生成之后才发生的，所以不能被访问。
这些记录都是undo log链里面找的，先找最近记录，如果最近这一条记录事务id不符合条件，不可见的话，再去找上一个版本再比较当前事务id和这个版本事务id看能不能访问，以此类推直到返回可见的版本或者结束。
举个例子，在已提交读隔离级别下：
比如此时有一个事务id为100的事务。修改了name,使得的name等于小明2，但是事务还没有提交。则此时的版本链是
那此时另一个事务发起了select语句要查询id为1的记录，那此时生成的readview列表只有[100]。那就去版本链去找了，首先肯定找最近的一条，发现trx_id是100，也就是name 为小明2的那条记录，发现在列表内，所以不能访问。
这时候就通过指针继续找下一条，name为小明1的记录发现trx_id是60，小于列表中的最小id,所以可以访问，直接访问结果为小明1.
那这时候 我们把事务ID为100的事务提交了，并且新建了一个事务id为110也修改id为1的记录，并且不提交事务。
这时候之前那个select事务又执行了一次查询，要查询id为1的记录。
已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的readView,而可重复读 隔离 级别则在第一次读的时候生成一个readview,之后的读都复用之前的readview。
1）如果你是已提交读隔离级别，这时候你会重新一个readview,那你的活动事务列表中的值就变了，变成了[110]。按照上的说法，你去版本链通过trx_id对比查找到合适的结果就是小明2。
2）如果你是可重复读隔离级别，这时候 你的readview还是第一次select时候生成的readview,也就是列表的值还是[100]。所以select 的结果是小明1。所以第二次select结果和第一次一样，所以叫可重复读。
这就是mysql的MVCC,通过版本链，实现多版本，可并发读-写，写-读。通过readview生成策略的不同实现不同的隔离级别。
13.MySQL的锁的类型有哪些呢？
说两个维度：
共享锁（简称S锁）和排他锁（简称X锁）
读锁是共享的，可以通过lock in share mode实现，这时候只能读不能写。
写锁是排他的，它会阻塞其他的写锁和读锁。从颗粒度来区分，可以分为表锁和行锁两种。
表锁和行锁
表锁会锁定整张表并且阻塞其他用户对该表的所有读写操作，比如alter修改表结构的时候会锁表。
行锁又可以分为乐观锁和悲观锁。
悲观锁可以通过for update实现。
乐观锁则通过版本号实现。
两个维度结合来看：
共享锁（行锁）：shared locks
读锁（s锁），多个事务对于同一数据可以共享访问，不能操作修改。
使用方法：
加锁： select * from table where id=1 lock in share mode
释放锁：commit/rollback
排他锁（行锁）：Exclusive Locks
写锁（X锁）,互斥锁/独占锁，事务获取了一个数据的X锁，其他事务就不能再获取该行的读锁和写锁（S锁、X锁），只有获取了该排他锁的事务是可以对数据进行读取和修改。
使用方法：
delete/update/insert --加锁
select * from table where ... for update --加锁
commit/rollback --释放锁
意向共享锁（IS）
一个数据行加共享锁前必须先取得该表的IS锁，意向共享锁之间是可以相互兼容的，意向排他锁（IX）一个数据行加排他锁前必须先取得该表的IX锁，意向排他锁之间是可以相互兼容的，意向锁（IS、IX）是Innodb引擎操作数据之前自动加的，不需要用户干预；意义：当事务操作需要锁表时，只需要判断意向锁是否存在，存在时则可快速返回该表不能启用表锁。
意向共享锁（IS锁）（表锁）：intention shared locks
表示事务准备给数据行加入共享锁，也就是说一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX锁）（表锁）：intention exclusive locks
表示事务准备给数据行加入排他锁，说明事务在一个数据行加排他锁前必须先取得该表的IX锁。
14.你们数据量级多大？分库分表是怎么做的？
首先分库分表分为垂直和水平两个方式，一般来说我们拆分的顺序是先垂直后水平。
垂直分库
基于现在的微服务拆分来说，都是已经做到了垂直分库了。
垂直分表
垂直切分是将一张表按照列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分将经常被使用的列和不经常使用的列切分到不同的表中。
在数据库的层面使用垂直切分将数据库中表的密集程度部署到不同的库中。例如将原来的电商数据库垂直切分成商品数据库、用户数据库。
水平分表
首先根据业务场景来决定使用什么字段作为分表字段（sharding_key),比如我们现在的日订单1000万。我们大部分的场景来源于C端，我们可以使用user_id作为sharding_key,数据查询支持到最近3个月的订单，超过3个月的做归档处理，那么三个月的数据量就是9亿，可以分1024张表，那么每张表的数据也就大概在100万左右。
比如用户id为100，那我们都经过hash(100),然后对1024取模，就可以落到对应的表上了。
那分表后的id怎么保证唯一性呢？
因为我们主键默认都是自增的，那么分表之后的主键在不同表就肯定会有冲突了。有几个办法考虑：
设定步长，比如1-1024张彪我们分别设定1-1024的基础步长，这样子主键落到不同的表就不会冲突了。
分布式ID，自己实现一套分布式ID生成算法或者使用开源的比如雪花算法这种。
分表后不使用主键作为查询依据，而是每张表单独新增一个字段作为唯一主键使用，比如订单表订单号是唯一的，不管最终落在哪张表都基于订单号座位查询依据，更新也一样。
15.分表后非分库字段sharding_key的查询怎么处理呢？
可以做一个mapping表，比如这时候商家要查询订单列表怎么办呢？不带user_id查询的话你总不能扫描全表吧，所以我们可以做一个映射关系表，保存商家和用户的关系，查询的时候先通过商家查询到用户列表，再通过user_id去查询。
一般而言，商户端对数据实时性要求并不是很高，比如查询订单列表，可以把订单列表同步到离线（实时）数仓，再基于数仓去做成一张宽表，在依据其他如ES 提供查询服务。
数据量不是很大的话，比如后台的一些查询之类的，也可以通过多线程扫表，然后再聚合结果的方式来做。或者异步的形式也是可以的。
2984
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
