-
mysql 数据是怎么存储的？ 数据持久化是存储在磁盘里的。系统中对于数据的存储有自己的规范，按可操作对象大小从小到大排序依次是: 扇区512 byte，块4kb，innodb引擎最小单元是页 16kb。mysql中的数据是有固定的数据结构的，啊1个记录可根据字段类型，多少大致计算出。1页可以存多条数据，以1行数据1kb为例 16kb / 1kb = 16。
-
mysql索引原理？ mysql为了支持成千上万条数据查询，内部存储按照一定规矩进行排列的。 Mysql数据结构是b+树，写入到磁盘的数据是按树形结构排列的，根节点，叶节点，叶子节点这么排列。每1个节点存储的都是：键值和指针(记录value的地址)。以一个树高为三的存储为例，根节点(页)，叶节点，叶子节点3层。数据存放在叶子节点的。 查找是基于二分查找法，问题就是从头和尾，向中间逼近进行查找。所以是用mysql进行数条件查询的时候，首先需要找到所有的数据，然后在内存中做过滤。这种方式其实也有缺点。查找效率受树高的限制，如果数据表中存储了大量的数据，那么它的树高会非常高，当进行查找时，会遍历到叶子结点，也就是最下面的那一层。这会导致增加查询时长。 主键索引和普通索引，查找效率的区别。主键索引只有一个，所以在进行查找时，最终直接就找到了一个答案。但是普通索引可以有多个，这种需要根据条件判断，找出一个合适的答案。但是两者查询效率是差别不大的。
-
具体查找底层原理。 where like 聚集索引，非聚集索引
-
为什么要分库？现在动辄就是高并发的场景，一下来了很多个请求，如果不分库的话，可能一下子就把数据库的链接打爆了。
-
为什么要分表？当数据量非常多的时候，数据查询是有瓶颈的。举个例子，如果数据量达到千万这个级别。那么b加树的树高是3。查找过程中非常耗时。 分表策略，按范围分表。哈西。一致性哈希。 哈系的问题。当需要数据扩容时，前面的数据顺序都会被打乱，重新计算。所以为了避免数据增加时调整原有数据的位置。一致性哈希算法解决了哈希算法不便于动态扩容的问题。
-
如何避免写倾斜？比如采取时间范围分段，电商在某一个时间段集中搞了一个大促活动，写了大量的数据，但在其他时间段数据都非常小。这种问题就叫写倾斜问题，也叫热点数据问题。油画棒的方法就是。range范围+hash取模。对某一个范围的分片数据，进行再一步细分。一个运气范围数据分为做个哈希块，在进行查找的时候，可以独立进行查找。避免了热点数据问题。
-
分片表的读写。写入是按一个个区块写的。读取的并发性能提高了。传统的一个表相当于拆成多个表，对磁盘io的性能提升是成倍的。
-
如何解决分库分表的数据一致性问题。 常见的分布式解决， tcc saga 两阶段提交。三阶中提交。 本地消息表。尽最大努力通知。
-
如何解决跨节点join的问题。 字段冗余，把业务中可能用到的字段都存到表里面。 全局表，系统中所有模块个人都需要一份相同的数据那么我们在数据标中都把这个数据都给存进 去，后面就不用从其它节点获取数据了。 应用层代码组装，分多次查询，获取到数据后再对需要的字段做组装。
-
聚合函数问题: ordey by, group by都需要找到全部数据再进一步做处理。只有在各个节点中获取所有数据，最后做聚合，最后做分组，排序等等。
-
分表数据分页问题: 服务端汇聚，再分页。缺点，网络io耗时大，也耗费服务器cpu资源。
-
分布式id：uuid生成算法，雪花
