- mysl存储引擎有什么 区别在哪里
- mysql的索引有哪些
- B树和B+树有什么不同
- 索引优化
- 索引的优点
- 索引的使用条件
- sql优化
- 谈谈explain
- 事物特性及隔离级别
- 事物实现原理
- mysql的锁有哪些
- 谈谈MVCC原理
- 锁算法
- 如何避免幻读
- 主从延时如何处理
- 分库分表如何实现的
- 数据主从复制原理
- 读写分离实现，若有延时如何处理
- 事物特性是如何实现的
- 查询语句的执行过程
- 更新语句的执行过程
- orderby的执行流程
- mysql集群
- sql执行慢的愿意
- redo log写入机制、存储形式
- undo log的作用，存储方式
- Binlog的写入机制和模式
- 什么是脏页，什么时候刷新它
- change buffer是什么
- mysl存储引擎有什么 区别在哪里
-
事务：InnoDB 是事务型的，可以使用 Commit 和 Rollback 语句。
-
并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。
-
外键：InnoDB 支持外键。
-
备份：InnoDB 支持在线热备份。
-
崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
-
其它特性：MyISAM 支持压缩表和空间数据索引。
- mysql的索引有哪些
B+ Tree 索引、哈希索引、全文索引、空间数据索引
B+ Tree 索引：不用全表扫描，只要对树根进行搜索即可、有序还可以查找和排序、包含聚簇索引和非聚簇索引、唯一索引-主键索引-普通索引-联合索引
哈希索引：O(1)时间查找不能排序和分组，只能精确查找
全文索引：查找条件使用 MATCH AGAINST，而不是普通的 WHERE、使用倒排索引实现，它记录着关键词到其所在文档的映射。
空间数据索引：MyISAM 存储引擎支持空间数据索引（R-Tree），可以用于地理数据存储
- B树和B+树有什么不同
B+树分为内部节点和叶子节点，其中叶子节点放置数据内部节点放索引信息，叶子节点通过顺序访问的指针相连接
使用B+树的好处：存储数据更多、查询磁盘io使用少、遍历效率高
- 索引优化
区分度高的索引放在前面、使用覆盖索引、对索引的字段不要进行加工比如函数或者计算
- 索引的优点
减少扫描行数、方便排序和分组、随机io变成顺序io
- 索引的使用条件
小表可以没有，因为使用索引要回表、中表使用比较好、超大的最好能分区
- sql优化
- 减少请求的数据量
只返回必要的列：最好不要使用 SELECT * 语句。
只返回必要的行：使用 LIMIT 语句来限制返回的数据。
缓存重复查询的数据：使用缓存可以避免在数据库中进行查询，特别在要查询的数据经常被重复查询时，缓存带来的查询性能提升将会是非常明显的。
- 减少服务器端扫描的行数
最有效的方式是使用索引来覆盖查询。
- 切分大查询
-
分解大连接查询
让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
减少锁竞争；
在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可伸缩。
查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。
- 谈谈explain
| id | SELECT识别符。这是SELECT的查询序列号 |
| select_type | SELECT类型,可以为以下任何一种:
|
| table | 输出的行所引用的表 |
| type | 联接类型。下面给出各种联接类型,按照从最佳类型到最坏类型进行排序:
|
| possible_keys | 指出MySQL能使用哪个索引在该表中找到行 |
| key | 显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。 |
| key_len | 显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。 |
| ref | 显示使用哪个列或常数与key一起从表中选择行。 |
| rows | 显示MySQL认为它执行查询时必须检查的行数。多行之间的数据相乘可以估算要处理的行数。 |
| filtered | 显示了通过条件过滤出的行数的百分比估计值。 |
| Extra | 该列包含MySQL解决查询的详细信息
|
- 事物特性及隔离级别
特性：原子性、一致性、隔离性、持久性
原子性 事务被视为不可分割的最小单元，事务的所有操作要么全部成功，要么全部失败回滚。
一致性 数据库在事务执行前后都保持一致性状态，在一致性状态下，所有事务对一个数据的读取结果都是相同的。
隔离性 一个事务所做的修改在最终提交以前，对其他事务是不可见的。
持久性 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢。
级别：读未提交、读已提交、可重复读、串行化
解决：XXX、脏读、不可重复读、幻读
- 事物实现原理
- 事务的原子性是通过 undo log 来实现的
- 事务的持久性性是通过 redo log 来实现的
- 事务的隔离性是通过 (读写锁+MVCC)来实现的
- 而事务的终极大 boss 一致性是通过原子性，持久性，隔离性来实现的！！！
- mysql的锁有哪些
- 锁类型 共享锁（S Lock） 允许事务读一行数据
- 排他锁（X Lock） 允许事务删除或者更新一行数据
- 意向共享锁（IS Lock） 事务想要获得一张表中某几行的共享锁
- 意向排他锁 事务想要获得一张表中某几行的排他锁
锁算法
- Record Lock 锁定一个记录上的索引，而不是记录本身。 如果表没有设置索引，InnoDB 会自动在主键上创建隐藏的聚簇索引，因此 Record Locks 依然可以使用。
- Gap Lock 锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。 SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
- Next-Key Lock 它是 Record Locks 和 Gap Locks 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。例如一个索引包含以下值：10, 11, 13, and 20，那么就需要锁定以下区间： (-∞, 10] (10, 11] (11, 13] (13, 20] (20, +∞) 在 InnoDB 存储引擎中，SELECT 操作的不可重复读问题通过 MVCC 得到了解决，而 UPDATE、DELETE 的不可重复读问题通过 Record Lock 解决，INSERT 的不可重复读问题是通过 Next-Key Lock（Record Lock + Gap Lock）解决的。
- 谈谈MVCC原理
每一行记录都有两个隐藏列：DATA_TRX_ID、DATA_ROLL_PTR
DATA_TRX_ID 记录最近更新这条行记录的事务 ID，大小为 6 个字节
DATA_ROLL_PTR 表示指向该行回滚段（rollback segment）的指针，大小为 7 个字节，InnoDB 便是通过这个指针找到之前版本的数据。该行记录上所有旧版本，在 undo 中都通过链表的形式组织。
DB_ROW_ID 行标识（隐藏单调自增 ID），大小为 6 字节，如果表没有主键，InnoDB 会自动生成一个隐藏主键，因此会出现这个列。另外，每条记录的头信息（record header）里都有一个专门的 bit（deleted_flag）来表示当前记录是否已经被删除。
Undo 日志
MVCC 使用到的快照存储在 Undo 日志中，该日志通过回滚指针把一个数据行（Record）的所有快照连接起来。
实现过程
以下实现过程针对可重复读隔离级别。
当开始一个事务时，该事务的版本号肯定大于当前所有数据行快照的创建版本号，理解这一点很关键。数据行快照的创建版本号是创建数据行快照时的系统版本号，系统版本号随着创建事务而递增，因此新创建一个事务时，这个事务的系统版本号比之前的系统版本号都大，也就是比所有数据行快照的创建版本号都大。
- SELECT 多个事务必须读取到同一个数据行的快照，并且这个快照是距离现在最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。把没有对一个数据行做修改的事务称为 T，T 所要读取的数据行快照的创建版本号必须小于等于 T 的版本号，因为如果大于 T 的版本号，那么表示该数据行快照是其它事务的最新修改，因此不能去读取它。除此之外，T 所要读取的数据行快照的删除版本号必须是未定义或者大于 T 的版本号，因为如果小于等于 T 的版本号，那么表示该数据行快照是已经被删除的，不应该去读取它。
- INSERT 将当前系统版本号作为数据行快照的创建版本号。
- DELET 将当前系统版本号作为数据行快照的删除版本号。
- UPDATE 将当前系统版本号作为更新前的数据行快照的删除版本号，并将当前系统版本号作为更新后的数据行快照的创建版本号。可以理解为先执行 DELETE 后执行 INSERT。
当前读
MVCC 其它会对数据库进行修改的操作（INSERT、UPDATE、DELETE）需要进行加锁操作，从而读取最新的数据。可以看到 MVCC 并不是完全不用加锁，而只是避免了 SELECT 的加锁操作。
快照读
MVCC 的 SELECT 操作是快照中的数据，不需要进行加锁操作。
- 如何避免幻读
Next-Key Lock（Record Lock + Gap Lock）
- 主从延时如何处理
原因：主库DML请求频繁、主库执行大事务、主库对大表执行DDL语句、主库与从库配置不一致、从库自身压力过大、表缺乏主键或合适索引
方案：
一、首先，假如你的业务时间允许，你可以在写入主库的时候，确保数据都同步到从库了之后才返回这条数据写入成功，当然如果有多个从库，你也必须确保每个从库都写入成功。显然，这个方案对性能和时间的消耗是极大的，不推荐。
二、另外一种就是，可以引入redis或者其他nosql数据库来存储我们经常会产生主从延迟的业务数据。当我在写入数据库的同时，我再写入一份到redis中。然后用户去读取数据的时候发现没有读取到这个数据，那么我们就可以再去查看redis中是否有这个数据，如果有我们就可以直接从redis中读取这个数据。当数据真正同步到数据库中的时候，再从redis中把数据删除。
三、任何的服务器都是有吞吐量的限制的，没有任何一个方案可以无限制的承载用户的大量流量。所以我们必须估算好我们的服务器能够承载的流量上限是多少。达到这个上限之后，就要采取缓存，限流，降级的这三大杀招来应对我们的流量。这也是应对主从延迟的根本处理办法。
四、既然主从延迟是由于从库写库不及时引起的，那我们也可以在有主从延迟的地方改变读库方式，由原来的读从库改为读主库。当然这也会增加代码的一些逻辑复杂性。
- 数据主从复制原理
- 同步复制: 指的是客户端连接到MySQL主服务器写入一段数据, MySQL主服务器同步给MySQL从服务器需要等待从服务器发出同步完成的响应才返回客户端OK, 这其中等待同步的过程是阻塞的, 如果有N台从服务器, 效率极低
- 异步复制: 指的是客户端连接到MySQL主服务器写入一段数据, MySQL主服务器将写入的数据发送给MySQL从服务器, 然后直接返回客户端OK, 可能从服务器的数据会和主服务不一致
- 半同步复制:指的是客户端连接到MySQL主服务器写入一段数据, MySQL主服务器只将数据同步复制给其中一台从服务器, 半同步复制给其他的从服务器, 来达到其中一台从服务器完全同步的效果
- 读写分离实现，若有延时如何处理
主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。
读写分离能提高性能的原因在于：
-
主从服务器负责各自的读和写，极大程度缓解了锁的争用；
-
从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
-
增加冗余，提高可用性。
读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。
- 更新语句的执行过程
- 1.连接数据库，这是连接器的工作。
- 2.查询缓存会失效，所以不用。
- 3.分析器会通过词法和语法解析知道这是一条更新语句。
- 4.优化器决定要使用ID这个索引。
- 5. 执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
- 6.执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
- 7.引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
- 8.执行器生成这个操作的binlog，并把binlog写入磁盘。
- 9.执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交
- orderby的执行流程
全字段排序 和 rowid 排序
全字段排序
- 1.初始化 sort_buffer，确定放入 name、city、age 这三个字段；
- 2.从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID_X；
- 3.到主键 id 索引取出整行，取 name、city、age 三个字段的值，存入 sort_buffer 中；
- 4.从索引 city 取下一个记录的主键 id；
- 5.7重复步骤 3、4 直到 city 的值不满足查询条件为止，对应的主键 id 也就是图中的 ID_Y；
- 6.对 sort_buffer 中的数据按照字段 name 做快速排序；
- 7.按照排序结果取前 1000 行返回给客户端。
如果要排序的数据量小于 sort_buffer_size，排序就在内存中完成。但如果排序数据量太大，内存放不下，则不得不利用磁盘临时文件辅助排序。MySQL 将需要排序的数据分成 12 份，每一份单独排序后存在这些临时文件中。然后把这 12 个有序文件再合并成一个有序的大文件。
rowid 排序是因为单行长度太大只记录排序字段和形影的主键id
- mysql集群
- sql执行慢的原因
没索引、大事物
- redo log写入机制、存储形式
⦁ 存储形式 可以配置为一组4个文件，每个文件的大小是1GB
⦁ 如何写 从头开始写，写到末尾就又回到开头循环写
write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。
checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
write pos和checkpoint之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果write pos追上checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。
⦁ 作用
有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。
从 redo log 可能存在的三种状态说起。
- 存在 redo log buffer 中，物理上是在 MySQL 进程内存中，就是图中的红色部分；
- 写到磁盘 (write)，但是没有持久化（fsync)，物理上是在文件系统的 page cache 里面，也就是图中的黄色部分；
- 持久化到磁盘，对应的是 hard disk，也就是图中的绿色部分。
日志写到 redo log buffer 是很快的，wirte 到 page cache 也差不多，但是持久化到磁盘的速度就慢多了。
为了控制 redo log 的写入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取值：
1.设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;
2.设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；
3.设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。
InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。
- undo log的作用，存储方式
undo log有两个作用：提供回滚和多个行版本控制(MVCC)。
innodb存储引擎对undo的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有1024个undo log segment。
delete/update操作的内部机制
当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。
但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。
delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
update分为两种情况：update的列是否是主键列。
如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
如果是主键列，update分两部执行：先删除该行，再插入一行目标行。
- Binlog的写入机制和模式
MySQL binlog的几种模式
（1）Row level
日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。
优点：能清楚的记录每一行数据修改的细节
缺点：数据量太大
（2）Statement level（默认）
每一条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行
优点：解决了 Row level下的缺点，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高新能
缺点：容易出现主从复制不一致
（3）Mixed（混合模式）
结合了Row level和Statement level的优点
binlog 的写入逻辑比较简单：事务执行过程中，先把日志写到 binlog cache（write），事务提交的时候，再把 binlog cache 写到 binlog 文件中（fsync）。系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。
write 和 fsync 的时机，是由参数 sync_binlog 控制的：
- sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync；
- sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；
- sync_binlog=N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才 fsync。
- 什么是脏页，什么时候刷新它
第一种是“redo log 写满了，要 flush 脏页”
第二种是“内存不够用了，要先将脏页写到磁盘”，这种情况其实是常态。
第三种情况是属于 MySQL 空闲时的操作
第四种情况是属于 MySQL关机
刷脏页还有连坐机制
- change buffer是什么
- 分库分表如何实现的
水平+垂直
分库分表问题：
1、事务问题
解决事务问题目前有两种可行的方案：分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。
方案一：使用分布式事务
优点：交由数据库管理，简单有效
缺点：性能代价高，特别是shard越来越多时
方案二：由应用程序和数据库共同控制
原理：将一个跨多个数据库的分布式事务分拆成多个仅处 于单个数据库上面的小事务，并通过应用程序来总控 各个小事务。
优点：性能上有优势
缺点：需要应用程序在事务控制上做灵活设计。如果使用 了spring的事务管理，改动起来会面临一定的困难。
2、跨节点Join的问题
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
3、跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
4、数据迁移，容量规划，扩容等问题
来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
5、事务
分布式事务
优点
基于两阶段提交，最大限度地保证了跨数据库操作的“原子性”，是分布式系统下最严格的事务实现方式。
实现简单，工作量小。由于多数应用服务器以及一些独立的分布式事务协调器做了大量的封装工作，使得项目中引入分布式事务的难度和工作量基本上可以忽略不计。
缺点
系统“水平”伸缩的死敌。基于两阶段提交的分布式事务在提交事务时需要在多个节点之间进行协调,最大限度地推后了提交事务的时间点，客观上延长了事务的执行时间，这会导致事务在访问共享资源时发生冲突和死锁的概率增高，随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平伸缩的"枷锁"， 这是很多Sharding系统不采用分布式事务的主要原因。
基于Best Efforts 1PC模式的事务
参考spring-data-neo4j的实现。鉴于Best Efforts 1PC模式的性能优势，以及相对简单的实现方式，它被大多数的sharding框架和项目采用
事务补偿（幂等值）
对于那些对性能要求很高，但对一致性要求并不高的系统，往往并不苛求系统的实时一致性，只要在一个允许的时间周期内达到最终一致性即可，这使得事务补偿机制成为一种可行的方案。事务补偿机制最初被提出是在“长事务”的处理中，但是对于分布式系统确保一致性也有很好的参考意义。笼统地讲，与事务在执行中发生错误后立即回滚的方式不同，事务补偿是一种事后检查并补救的措施，它只期望在一个容许时间周期内得到最终一致的结果就可以了。事务补偿的实现与系统业务紧密相关，并没有一种标准的处理方式。一些常见的实现方式有：对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步，等等。
6、ID问题
一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由.
一些常见的主键生成策略
a。UUID
使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。
结合数据库维护一个Sequence表
b。Twitter的分布式自增ID算法Snowflake
在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。
7、跨分片的排序分页
一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。
8、分库策略
分库维度确定后，如何把记录分到各个库里呢?
一般有两种方式：
根据数值范围，比如用户Id为1-9999的记录分到第一个库，10000-20000的分到第二个库，以此类推。
根据数值取模，比如用户Id mod n，余数为0的记录放到第一个库，余数为1的放到第二个库，以此类推。
优劣比较：
评价指标按照范围分库按照Mod分库
库数量前期数目比较小，可以随用户/业务按需增长前期即根据mode因子确定库数量，数目一般比较大
访问性能前期库数量小，全库查询消耗资源少，单库查询性能略差前期库数量大，全库查询消耗资源多，单库查询性能略好
调整库数量比较容易，一般只需为新用户增加库，老库拆分也只影响单个库困难，改变mod因子导致数据在所有库之间迁移
数据热点新旧用户购物频率有差异，有数据热点问题新旧用户均匀到分布到各个库，无热点
实践中a为了处理简单，选择mod分库的比较多。同时二次分库时，为了数据迁移方便，一般是按倍数增加，比如初始4个库，二次分裂为8个，再16个。这样对于某个库的数据，一半数据移到新库，剩余不动，对比每次只增加一个库，所有数据都要大规模变动。
补充下，mod分库一般每个库记录数比较均匀，但也有些数据库，存在超级Id，这些Id的记录远远超过其他Id，比如在广告场景下，某个大广告主的广告数可能占总体很大比例。如果按照广告主Id取模分库，某些库的记录数会特别多，对于这些超级Id，需要提供单独库来存储记录。
9、分库数量
分库数量首先和单库能处理的记录数有关，一般来说，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。
在满足上述前提下，如果分库数量少，达不到分散存储和减轻DB性能压力的目的；如果分库的数量多，好处是每个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序需要访问多个库，如果是并发模式，要消耗宝贵的线程资源；如果是串行模式，执行时间会急剧增加。
最后分库数量还直接影响硬件的投入，一般每个分库跑在单独物理机上，多一个库意味多一台设备。所以具体分多少个库，要综合评估，一般初次分库建议分4-8个库。
10、路由透明
分库从某种意义上来说，意味着DB schema改变了，必然影响应用，但这种改变和业务无关，所以要尽量保证分库对应用代码透明，分库逻辑尽量在数据访问层处理。当然完全做到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：
对于单库访问，比如查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。
对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。
mycat 和shardingjdbc
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
