一条语句没法实现的... create table table2 select * from table1 order by id limit 1,100 create table table3 select * from table1 order by id limit 100,100 create table table4 select * from table1 order by id limit 200,100
10年积累的成都网站设计、成都网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先做网站设计后付款的网站建设流程，更有融水免费网站建设让你可以放心的选择与我们合作。
将所有数据都迁移到mycat中，一共有4个数据库，blog01，blog02，blog_article01，blog_article02。
article，article_tags分别在blog_article01，blog_article02，按照uid进行水平拆分。
user_info表在blog01，link，category，tag在blog02数据库中。
mysql分库分表一般有如下场景
其中1，2相对较容易实现,本文重点讲讲水平拆表和水平拆库,以及基于mybatis插件方式实现水平拆分方案落地。
在 《聊一聊扩展字段设计》 一文中有讲解到基于KV水平存储扩展字段方案,这就是非常典型的可以水平分表的场景。主表和kv表是一对N关系,随着主表数据量增长,KV表最大N倍线性增长。
这里我们以分KV表水平拆分为场景
对于kv扩展字段查询,只会根据id + key 或者 id 为条件的方式查询,所以这里我们可以按照id 分片即可
分512张表(实际场景具体分多少表还得根据字段增加的频次而定)
分表后表名为kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次类推!
水平分表相对比较容易,后面会讲到基于mybatis插件实现方案
场景:以下我们基于博客文章表分库场景来分析
目标:
表结构如下(节选部分字段):
按照user_id sharding
假如分1024个库,按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001库
user_id % 1024 = 2 分到db_002库
依次类推
目前是2个节点,假如后期达到瓶颈,我们可以增加至4个节点
最多可以增加只1024个节点,性能线性增长
对于水平分表/分库后,非shardingKey查询首先得考虑到
基于mybatis分库分表,一般常用的一种是基于spring AOP方式, 另外一种基于mybatis插件。其实两种方式思路差不多。
为了比较直观解决这个问题,我分别在Executor 和StatementHandler阶段2个拦截器
实现动态数据源获取接口
测试结果如下
由此可知,我们需要在Executor阶段 切换数据源
对于分库:
原始sql:
目标sql:
其中定义了三个注解
@useMaster 是否强制读主
@shardingBy 分片标识
@DB 定义逻辑表名 库名以及分片策略
1)编写entity
Insert
select
以上顺利实现mysql分库,同样的道理实现同时分库分表也很容易实现。
此插件具体实现方案已开源:
目录如下:
mysql分库分表,首先得找到瓶颈在哪里(IO or CPU),是分库还是分表,分多少？不能为了分库分表而拆分。
原则上是尽量先垂直拆分 后 水平拆分。
以上基于mybatis插件分库分表是一种实现思路,还有很多不完善的地方,
例如:
一、优化表的数据类型
select * from tablename procedure analyse();
select * from tablename procedure analyse(16.265);
上面输出一列信息，牟你数据表的字段提出优化建义，
二、通过拆分表提高数据访问效率
拆分一是指针对表进行拆分，如果是针对myisam类型的表进行处理的话，可以有两种拆分方法
1、是垂直拆分，把主要的与一些散放到一个表，然后把主要的和另外的列放在另一张表。
2、水平拆分方法，根据一列或多列的值把数据行放到两个独立的表中，水平拆分通常几种情况。
表很大，拆分后可降低查询时数据和索引的查询速度，同时也降低了索引的层数，提高查询的速度。
表中的数据本来就有独立性，表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，厕国一些数据不常用的情况下，
需要把数据存放到多个不同的介质上。
三、逆规范化
四、使用中间表优化方法对于数据库教程大的表，在进行统计查询时通常会比较慢的，并且还要考虑查询是否会对在线应用产生影响，通常这种情况下我们使用中间表可以提高查询统计速度
