业务表tb_image部分数据如下所示,其中id唯一,image_no不唯一。image_no表示每个文件的编号,每个文件在业务系统中会生成若干个文件,每个文件的唯一ID就是字段id:
成都创新互联专注于企业全网营销推广、网站重做改版、金林网站定制设计、自适应品牌网站建设、H5场景定制、购物商城网站建设、集团公司官网建设、外贸营销网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为金林等各大城市提供网站开发制作服务。
业务表tb_image的一些情况如下:
根据上面对业务的分析,分库分表完全没有必要。单库分表的话,由于要根据image_no和id查询,所以,一种方案是冗余分表(即一份数据以image_no为分片键保存,另一份数据以id为分片键保存);另一种方案是只以image_no为分片键,而基于id的查询需求,业务层进行结果归并或者引入第三方中间件。
考虑到单库分表比较复杂,所以决定使用分区特性,而且容量评估分区表方案128个分区(每个分区数据量kw级别)完全能保证业务至少稳定运行15年(图中橙色部分是比较贴合自身业务实际增长情况):
另外,由于RANGE, LIST, HASH分区都不支持VARCHAR列,所以决定采用KEY分区,官方介绍它的原理是以MySQL内置hash算法然后对分区数取模。
选定分片键为image_no,并且决定分区数为128后,就要灌入数据进行可行性和性能测试了。分区数选择128的原因是:11亿/1kw=110≈128,另外程序员情节,喜欢用2的N次方,你懂的。然而, 这个分区数128就是一切噩梦的开始 。
我尝试先插入10w数据到128个分区中,插入后,让我惊讶的现象出现了: 所有奇数编号分区(p1, p3, p5, ... , p2n-1)中居然没有一条数据 ,同时,任何一个偶数编号分区却有很多的数据,而且还不是很均匀。如下图所示:
说明 :奇数编号分区的ibd文件大小都是112k,这是创建分区表时初始化大小,实际并没有任何数据。我们可以通过SQL: select partition_name, partition_expression, table_rows from information_schema.partitions where table_schema = schema() and table_name='image_subpart'; 验证,其部分结果如下图所示:
难道10w条数据还不够说明问题?平均下来每个分区可是有近800条数据!好吧,来点猛的:我再插入990w条数据,总计1kw数据。结果还是一样,奇数编号分区没有数据,偶数编号都有分区。
我们再来回想一下KEY分区的原理: 通过MySQL内置hash算法对分片键计算hash值后再对分区数取模 。这个原理也可以从MySQL官网找到,请戳链接: 22.2.5 KEY Partitioning: ,截取原文如下:
这个世界上不会有这么渣渣的hash算法吧? 随便写个什么算法也不至于这么不均匀吧?这时候我怀疑是否有一些什么配置引起的。但是 show variables 中并没有任何与partition相关的变量。
这个时候,一万匹马奔腾而过。会不会是文档和源码不同步导致的?好吧,看MySQL的源码,毕竟, 源码才是最接近真相的地方 。KEY分区相关源码在文件 sql_partition.cc 中,笔者截取部分关键源码,如下所示,初略观察,并没有什么不妥,先计算分区字段的hash值然后对分区数取模:
怀着绝望的心情,请出搜索引擎搜索:"KEY分区数据不均匀",搜索结果中的CSDN论坛( )里有个民间高手 华夏小卒 回答如下:
这个时候,又是一万匹马奔腾而过。不过F**K的同时,心里也是有点小激动,因为可能找到解决办法了(虽然还不知道MySQL内置hash算法为毛会这样),最后笔者再次对KEY分区测试并总结如下:
如下图所示,是笔者把分区数调整为127并插入100w数据后的情况,通过SQL证明每个分区的数据量几乎一样:
MySQL的KEY分区这么大的使用陷阱,居然在官方上没有任何说明,这让笔者感到非常震惊。笔者还尝试Google搜索 mysql partition key uneven ,也有很多结果,例如 stackoverflow: ,此外还有MySQL bug: Bug #72428 Partition by KEY() results in uneven data distribution
正在看此文并有很强烈兴趣的同学,可以尝试更深入这个问题。笔者接下来也会找个时间,根据MySQL源码深入挖掘其hash算法的实现为什么对分区数如此敏感。
MySQL的cluster方案有很多官方和第三方的选择,选择多就是一种烦恼,因此,我们考虑MySQL数据库满足下三点需求,考察市面上可行的解决方案:
高可用性:主服务器故障后可自动切换到后备服务器可伸缩性:可方便通过脚本增加DB服务器负载均衡:支持手动把某公司的数据请求切换到另外的服务器,可配置哪些公司的数据服务访问哪个服务器
需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点
查看mysql外键方式主要是通过第三方工具或者是sql语句,主要有以下三种方式
1、使用Navicateformysql,打开数据库、查看数据库表、查看设计表、选择外键选项卡,就可以查看外键
2、使用sql语句
showcreatetable表名;这个命令可以查看表的所有信息,包括一些字段类型,字段的约束,外键,主键,索引,字符编码等等。
3、查看某个表或者某个列的外键信息
selectTABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME,
REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAME from KEY_COLUMN_USAGE where REFERENCED_TABLE_NAME = 'table';
如果需要查看某一列上的外键关系,需要添加列的条件REFERENCED_COLUMN_NAME.xx=xx
方法一比较直观,方法三比较准确!
扩展资料:
MySQL是一种开放源代码的关系型数据库管理系统(RDBMS),MySQL数据库系统使用最常用的数据库管理语言--结构化查询语言(SQL)进行数据库管理。
由于MySQL是开放源代码的,因此任何人都可以在GeneralPublicLicense的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下,MySQL是管理内容最好的选择。
参考资料来源:百度百科——mySQL
几种获取MySQL分区表信息的常用方法
SHOW CREATE TABLE 可以查看创建分区表的CREATE语句
SHOW TABLE STATUS 可以查看表是否为分区表
查看INFORMATION_SCHEMA.PARTITIONS表 可以查看表具有哪几个分区、分区的方法、分区中数据的记录数等重要信息
EXPLAIN PARTITIONS SELECT 查看select语句怎样使用分区