由于最近總有人抱怨，數(shù)據(jù)遷移后執(zhí)行SQL變慢，經(jīng)過查看原來是分區(qū)導(dǎo)致的問題。原分區(qū)根據(jù)按月設(shè)置RANGE分區(qū)，

看到這圖的時(shí)候也許有人就會(huì)發(fā)現(xiàn)問題.......

業(yè)務(wù)查詢SQL：

從SQL上看 執(zhí)行計(jì)劃確實(shí)是走了分區(qū)，但為什么沒有命中索引呢，在圖1的里有聯(lián)合索引(idx_reportDate_groupID_shopID_saasOrderKey)

##解決問題思路

1、若強(qiáng)制指定走索引，確實(shí)是快的，掃描的行數(shù)也掃了

但由于業(yè)務(wù)修改比較麻煩，被要求要和其他庫統(tǒng)一索引，繼續(xù)不管....找問題先......

解決問題2：

猜測可能是表統(tǒng)計(jì)信息和碎片引起的，通過dump 還原操作，結(jié)果還是一樣沒解決問題......

解決問題3：

SQL查詢1號(hào)到10號(hào)跨的時(shí)間段比較長，難道是優(yōu)化器問題.....理論了解不多....繼續(xù)找問題

先把SQL 簡單化查詢操作 如select * from ....操作

發(fā)現(xiàn)效果還不錯(cuò)，此時(shí)修改查詢時(shí)間范圍。按業(yè)務(wù)查詢的SQL看看

發(fā)現(xiàn)問題了，按理應(yīng)該是在P27分區(qū)，怎么掃了這么多分區(qū)，這就能和第1圖定義的分區(qū)有關(guān)系了，定義分區(qū)出了問題，到這算真正找到問題了。

開始解決問題：

目前應(yīng)該想著怎么對(duì)3000W 表重構(gòu)分區(qū)，而且不能刪除原來數(shù)據(jù)都要保留著

方法1：

對(duì)于小表執(zhí)行ALTER 操作:alter table table_name remove partitioning; ?##移除分區(qū)，鎖表

線上可以使用pt-osc工具來移除分區(qū)，不影響業(yè)務(wù)

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

發(fā)現(xiàn)一移除分區(qū)查詢瞬間變快

圖索引剛加，在沒這個(gè)索引 也可使用令一索引

重構(gòu)分區(qū)：

小表自行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，如圖

重構(gòu)分區(qū)后，執(zhí)行計(jì)劃

其他驗(yàn)證，是否指定分區(qū):

總結(jié)

以上是生活随笔為你收集整理的mysql普通标转分区表_MySQL分区表到普通表互转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。