由於最近總有人抱怨，數據遷移後執行SQL變慢，經過查看原來是分區導致的問題。原分區根據按月設置RANGE分區，
看到這圖的時候也許有人就會發現問題.......
業務查詢SQL：
從SQL上看 執行計劃確實是走了分區，但爲什麼沒有命中索引呢，在圖1的裏有聯合索引(idx_reportDate_groupID_shopID_saasOrderKey)
##解決問題思路
1、若強制指定走索引，確實是快的，掃描的行數也掃了
但由於業務修改比較麻煩，被要求要和其他庫統一索引，繼續不管....找問題先......
解決問題2：
猜測可能是表統計信息和碎片引起的，通過dump 還原操作，結果還是一樣沒解決問題......
解決問題3：
SQL查詢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" 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
發現一移除分區查詢瞬間變快
圖索引剛加，在沒這個索引 也可使用令一索引
重構分區：
小表自行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，如圖
重構分區後，執行計劃
其他驗證，是否指定分區:
