查看: 3717|回复: 2
MySQL5.5使用字符串进行分区的范围设置？
论坛徽章:0
1， 表情况
现有一张约25万行的表，其中有几个字段加了索引did（主键），title，time等。
该表每天增加约10000条记录，（最终规模大概是3000万+级别，表大小50G+），所以考虑对它进行分区（注：不选择分表，因为需要改动php程序代码？！这个实现起来比较困难？！）。
2，字段情况
搜索的时候，80%情况下使用title搜索，其次是用did搜索，两者都建有索引，目前还是很快的。
did设置是int，自增
title设置是varchar(80)，主要是纯数字形式字符串（例如，，5677等，非连续），还有很少一些非数字字符串（例如，china，中国，A1233等）。
已经实现了按照did字段（int类型）进行hash分区，但是我认为这个似乎对sql语句（大约是select did, title, time, ...&&from table where title=&1234&）没有什么优化。
需要按照title进行分区，优化查询
语句大概是这样的：
..........
PARTITION BY RANGE COLUMNS (title)
(
&&PARTITION p00 VALUES LESS THAN (0),& && && && && &&&#####存储所有非纯数字形式的title
&&PARTITION p01 VALUES LESS THAN (500000),& && &&&#####存储纯数字形式小于50万的title
&&PARTITION p02 VALUES LESS THAN (1000000),& && &#####存储纯数字形式小于100万的title
&&PARTITION p03 VALUES LESS THAN (1500000),& && &#####存储纯数字形式小于150万的title
&&..........& && && && && && && && && && && && && && && && && && && && && & #####依次类推
&&PARTITION pn VALUES LESS THAN (),& && &#####存储纯数字形式小于2500万的title
&&PARTITION pn+1 VALUES LESS THAN (MAXVALUE)&&#####存储纯数字形式大于2500万的title，预计未来1年不会超过3000万，这个以后可以再添加分区
);复制代码
1，分区中VALUES LESS THAN (?) 里边该如何写？试了下'500000'之类不行（我不太清楚编码和范围，抱歉），或者可以使用between ... and ...?
2，分区后按照where title=xxx来搜索，是直接根据索引到某个分区中提取信息的吧？
3，其他方面的优化。
论坛徽章:0
liuhc 发表于
这种无规律的数据进行范围分区显然是不合适，需要进行中间转换
规律还是有的，可能比较不好转换吧。
不行的话只能把字段改成int，把不是int的给去掉了！
论坛徽章:0
这种无规律的数据进行范围分区显然是不合适，需要进行中间转换
您需要登录后才可以回帖
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：10　广播电视节目制作经营许可证：编号（京）字第1149号在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
mysql 5.1以后提供了表分区功能，这样以前需要我们在程序中做的分表，现在通过mysql就可以原生支持。但我的问题是分区功能是否稳定，有无线上应用实例性能如何，是否有所提高分区函数能否自定义
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
没有用过他的分区，我们是直接分库，用了阿里巴巴开源的一个框架:Corba.这个还是要看你具体的业务情况
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
1，没用过，但是从5.1到5.6，我觉得非海量应用，应该没问题。
2，性能应该优于自己做分区
3，有个partition by的操作，不知道能不能满足需求？支持哈希和按Key的方式，可以专门弄一个字段用程序算出来，作为partition的key
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
CSDN &《程序员》研发主编，投稿&纠错等事宜请致邮
你只管努力，剩下的交给时光！
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：www.xttblog.com。个人QQ群：、
个人大数据技术博客：https://www.iteblog.com升级到MySQL 5.7的又一个理由——分区问题_InsideMySQL_传送门
升级到MySQL 5.7的又一个理由——分区问题
Scott 姜承尧
InsideMySQL
前言经常有小伙伴问Inside君，MySQL的分区（partition）怎么样？能用不？是不是有很多bug？不知MySQL的分区为何会给普罗大众这样的印象。但Inside君的印象中，分区影响比较大的bug就下面的一例（严格意义也很难说是bug），也是小伙伴们咨询Inside君分区遇到最多的问题。不过，好在这个bug已在5.7版本中得到了修复（准确来说是5.7支持了Native Paritition）。看来又多了一个升级到5.7的理由。总结来说，生产环境有必要每天弄个分区嘛？PS：Inside君组织与策划的2016年MySQL技术嘉年华大会将于4月24日在上海开始，票价堪称业界良心，仅299元（3月1日前）。欢迎小伙伴们来参加与交流，一起打造最有态度的数据库大会。详情可见： 正文一个月之前，Scott和同事们发现公司有一个MySQL MHA集群的master（假设master机器名为hostA）每隔一周左右就会挂一次（指MySQL挂掉），在几周内，MHA来回切了好几次。按照国际惯例，Scott按照如下顺序去查问题到底出在哪里：1. 先翻MySQL error log，没有发现异常2. 再翻Linux系统日志文件，果然，翻到了下面的内容：Nov 26 13:05:38 hostA kernel: mysql invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0......Nov 26 13:05:38 hostA kernel: Out of memory: Kill process 32271 (mysqld) score 976 or sacrifice childNov 26 13:05:38 hostA kernel: Killed process 32271, UID 496, (mysqld) total-vm:kB, anon-rss:kB, file-rss:4544kB该机器的物理内存大小为62G，从上面的日志看，MySQL确实已经把它用满了。该机器上MySQL的innodb_buffer_pool=31G，Scott认为这已经相当保守了，而且各种buffer_size我们都使用的是默认值，MySQL OOM时的用户连接数是100+，这些目测都没有什么问题，但是居然还是发生了OOM，实在是不可思议。当时觉得就是内存不够用了呗，没有查出具体原因，后来62G的内存加到了125G（innodb_buffer_pool_size增大到64G，这值确实很保守），还是发生了OOM。其实一开始Scott就发现，这台机器上有一个更早的问题，就是因为系统最大文件打开数不够导致这台机器的xtrabackup备份总是不成功，具体是什么原因请等Scott去整理xtrabackup备份的更详细的过程。然后我去检查了该机器上面的*.ibd文件和*.frm文件数量，吓我一跳（话说Inside君也是吓尿了）：[userA@hostA mysql]$ sudo find . -name '*.ibd' | wc -l169577[userA@hostA mysql]$ sudo find . -name '*.frm' | wc -l2534也就是说，该机器上面竟然有17万个ibd文件，但是只有2534张表，很明显是分区表中的分区数量非常多。[userA@hostA mysql]$ sudo find . -name '*par*' | wc -l1882Scott仔细比较了这台机器和其他没有问题的机器的不同，发现这台机器上面分区数量太多是唯一的一个不同，这让Scott没有办法不怀疑是分区导致的问题。Scott仍然按照国际惯例，第一时间去查MySQL 5.6的官方文档，无果。。。（官方文档虽然不是万能的，但是仍然是出现问题的第一参考资料）。去MySQL的bugs页面搜索关于partition的bug，无果。。。去google了下，发现有的比较杂的网站上面写道MySQL分区数量太多引发内存耗尽的问题，但是文章讲的内容感觉不是很正确。最后在姜老师的指点下，看了这篇文章：http://mysqlserverteam.com/innodb-native-partitioning-early-access/上面是MySQL开发团队写的关于InnoDB Native Partitioning的文章。文章中大概讲的内容是，在5.6里面，分区的信息是在MySQL Server层维护的（在.par文件里面），InnoDB引擎层是不知道有分区这个概念的，InnoDB引擎层把每一个分区都当成一张普通的InnoDB表。在打开一个分区表时，会打开很多个分区，打开这些分区表就相当于打开了同等数量的InnoDB表，这需要更多内存存放InnoDB表的元数据和各种与ibd文件打开相关的各种cache与handler的信息。在5.7里面，InnoDB引入了Native Partitioning，它把分区的信息从Server层移到了InnoDB层，打开一个分区表和打开一个InnoDB表的内存开销基本是一样的。If we compare the amount of memory used when opening a single instance of this table, first using the old generic non-native partitioning, and then with InnoDB Native Partitioning we see the following:One open instance of the table takes 49% less memory (111MB vs 218MB) with the current state of Native Partitioning support. With ten open instances of the table, we take up 90% less memory (113MB vs 1166MB)!由于升级到5.7还需要一些时日，目前已经将分区数量减少到2G剩余内存在20天里一直稳定在20G左右，这也表明确实是分区数量太多的原因。
觉得不错，分享给更多人看到
InsideMySQL 微信二维码
分享这篇文章
InsideMySQL 最新头条文章
InsideMySQL 热门头条文章