先看一个现象 1 2 3 4 5 6 7 8 9 10 11 CREATE TABLE `type_test` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `num` bigint(20) unsigned NOT NULL, `str` varchar(1024) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `idx_num` (`num`) USING BTREE, KEY `idx_str` (`str`) USING BTREE ) DEFAULT CHARSET=utf8; EXPLAIN SELECT * FROM type_test where str=1; EXPLAIN SELECT * FROM type_test where num='13'; 你认为上述两个查询（输入的类型和实际类型不一致），是否都会命中索引呢？ ...
最近用到了分库分表，也见识到了某业务表数已经到了几万张。下面主要是对分库分表平滑扩容 这篇文章的学习和整理 分库分表 为了增加db的并发能力，常见的方案就是对数据进行分库分表 如果所有数据都塞到一个表里面，数据条数达到一定量级的时候，数据查询操作将会是一件很恐怖的事情 这个需要在初期对数据规划有一个预期，从而预先分配出足够的库来处理。 1 2 3 4 5 Service / | \ uid%3= 0 1 2 | | | DB A B C 数据会均衡地分到每个DB里面，查询的时候会根据余数来定位数据所在库或表 扩容及产生的问题 后续业务发展的速度很快，用户量数据大量上升，当前容量不足以支撑，应该怎么办？ 需要对数据库进行水平扩容，再增加新库来分解。新库加入之后，原先sharding到3个库的数据，就可以sharding到四个库里面了 1 2 3 4 5 6 — Service — / / \ \ / | | \ uid%4= 0 1 2 3 | | | | DB A B C D 不过此时由于分片规则进行了变化(uid%3 变为uid%4)，大部分的数据，无法命中在原有的数据库上了，需要重新分配，大量数据需要迁移。 ...