MySQL分区表到普通表互转

由于最近总有人抱怨,数据迁移后执行SQL变慢,经过查看原来是分区导致的问题。原分区根据按月设置RANGE分区,

MySQL分区表到普通表互转_第1张图片

看到这图的时候也许有人就会发现问题.......

业务查询SQL:

MySQL分区表到普通表互转_第2张图片

从SQL上看 执行计划确实是走了分区,但为什么没有命中索引呢,在图1的里有联合索引(idx_reportDate_groupID_shopID_saasOrderKey)

##解决问题思路

1、若强制指定走索引,确实是快的,扫描的行数也扫了

MySQL分区表到普通表互转_第3张图片

但由于业务修改比较麻烦,被要求要和其他库统一索引,继续不管....找问题先......

解决问题2:

   猜测可能是表统计信息和碎片引起的,通过dump 还原操作,结果还是一样没解决问题......

解决问题3:

  SQL查询1号到10号跨的时间段比较长,难道是优化器问题.....理论了解不多....继续找问题

  先把SQL 简单化查询操作 如select * from ....操作

MySQL分区表到普通表互转_第4张图片

发现效果还不错,此时修改查询时间范围。按业务查询的SQL看看

MySQL分区表到普通表互转_第5张图片

发现问题了,按理应该是在P27分区,怎么扫了这么多分区,这就能和第1图定义的分区有关系了,定义分区出了问题,到这算真正找到问题了。

开始解决问题:

目前应该想着怎么对3000W 表重构分区,而且不能删除原来数据都要保留着

方法1:

对于小表执行ALTER 操作:alter table table_name remove partitioning;  ##移除分区,锁表

线上可以使用pt-osc工具来移除分区,不影响业务

pt-online-schema-change -u load_data -h 192.168.21.113 -p root123 -P 3306 --alter=" REMOVE PARTITIONING" D=test,t=tbl_saas_order_food --charset=utf8 --no-version-check  --statistics --critical-load="Threads_running:200" --max-load="Threads_running=25" --print --execute

发现一移除分区查询瞬间变快

MySQL分区表到普通表互转_第6张图片

图索引刚加,在没这个索引 也可使用令一索引

重构分区:

小表自行alter table tabe_name PARTITION BY range(sid)(PARTITION p1512 VALUES LESS THAN (20160101),

 PARTITION p1601 VALUES LESS THAN (20160201),.........,PARTITION p888666 VALUES LESS THAN MAXVALUE)

大表:PT-OSC,如图


重构分区后,执行计划

MySQL分区表到普通表互转_第7张图片

其他验证,是否指定分区:

MySQL分区表到普通表互转_第8张图片




你可能感兴趣的:(MySQL)