临沂企业网站建设,企业短视频推广,青岛建站公司推荐,网站开发模合同由于最近总有人抱怨#xff0c;数据迁移后执行SQL变慢#xff0c;经过查看原来是分区导致的问题。原分区根据按月设置RANGE分区#xff0c;看到这图的时候也许有人就会发现问题.......业务查询SQL#xff1a;从SQL上看 执行计划确实是走了分区#xff0c;但为什么没有命中…由于最近总有人抱怨数据迁移后执行SQL变慢经过查看原来是分区导致的问题。原分区根据按月设置RANGE分区看到这图的时候也许有人就会发现问题.......业务查询SQL从SQL上看 执行计划确实是走了分区但为什么没有命中索引呢在图1的里有联合索引(idx_reportDate_groupID_shopID_saasOrderKey)##解决问题思路1、若强制指定走索引确实是快的扫描的行数也扫了但由于业务修改比较麻烦被要求要和其他库统一索引继续不管....找问题先......解决问题2猜测可能是表统计信息和碎片引起的通过dump 还原操作结果还是一样没解决问题......解决问题3SQL查询1号到10号跨的时间段比较长难道是优化器问题.....理论了解不多....继续找问题先把SQL 简单化查询操作 如select * from ....操作发现效果还不错此时修改查询时间范围。按业务查询的SQL看看发现问题了按理应该是在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 Dtest,ttbl_saas_order_food --charsetutf8 --no-version-check --statistics --critical-loadThreads_running:200 --max-loadThreads_running25 --print --execute发现一移除分区查询瞬间变快图索引刚加在没这个索引 也可使用令一索引重构分区小表自行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如图重构分区后执行计划其他验证是否指定分区:
