通常のテーブルHuzhuanへのMySQLのパーティションテーブル

問題のパーティションの元の原因を表示した後、以降の遅いデータ移行文句SQLの最近の実現のためには、常に誰か。元のパーティションによると、毎月RANGEパーティションを設定し、

この図を参照して、おそらく誰かが問題を見つけるだろう.......

ビジネスのお問い合わせのSQL：

ビューのSQLの実行計画の観点から、本当になくなってパーティションですが、それがインデックスにヒットしなかった理由を、図1の中で共同指数（idx_reportDate_groupID_shopID_saasOrderKey）があります

##問題を解決するためのアイデア

指定されたインデックスを取ることを余儀なく場合は1、それは本当に速いですが、また、行数は、スイープをスキャン

しかし、ビジネスを変更するにはあまりにも多くの問題に起因する、私たちは前に問題を発見していきかかわらず....で、図書館や他の統一されたインデックスに求めていた......

この問題を解決するために2：

投機は、表統計およびリストア操作のダンプによって引き起こされる破片であってもよいし、その結果は、まだ問題は解決していないと同じです......

この問題を解決するために3：

時間スパンの比較的長い期間の10日に第1号にSQLクエリ、それは理論上の問題で、オプティマイザで.....あまり知らない....問題を発見し続けます

こうしたから....動作選択*としてまずSQLクエリの簡素化の操作

これは、クエリ時間を変更し、その後、結果が良いことがわかりました。ビジネスルックによるSQLクエリ

問題を発見し、論理的に図1で定義されており、パーティションは問題外の関係規定されたパーティションを持つことができるように多くのパーティションを、掃引する方法を、P27のパーティションにする必要があり、これは問題を見つけることが本当にあります。

問題を解決するために開始します。

現時点では3000Wは、パーティションテーブルを再構築する方法を考えるべきであるが、保持するために元のデータを削除することはできません。

方法1：

小さなALTERテーブルの操作を実行：ALTER表table_name削除分割を、##パーティションを削除、ロックテーブル

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

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