シンプルカウントidが65.5万行を持つテーブルに私が持っている長い

Question

に取っている： 1）

CREATE TABLE RawData1 (
    cdasite varchar(45) COLLATE utf8_unicode_ci NOT NULL, 
    id int(20) NOT NULL DEFAULT '0', 
    timedate datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
    type int(11) NOT NULL DEFAULT '0', 
    status int(11) NOT NULL DEFAULT '0', 
    branch_id int(20) DEFAULT NULL, 
    branch_idString varchar(64) COLLATE utf8_unicode_ci DEFAULT NULL, 
    PRIMARY KEY (id,cdasite,timedate), 
    KEY idx_timedate (timedate,cdasite) 
) ENGINE=InnoDB; 

2）パーティションを持つ 同じテーブル（RawData2それを呼び出す）

PARTITION BY RANGE (TO_DAYS(timedate)) 
(PARTITION p20140101 VALUES LESS THAN (735599) ENGINE = InnoDB, 
PARTITION p20140401 VALUES LESS THAN (735689) ENGINE = InnoDB, 
. 
. 
PARTITION p20201001 VALUES LESS THAN (738064) ENGINE = InnoDB, 
PARTITION future VALUES LESS THAN MAXVALUE ENGINE = InnoDB); 

SELECT count(id) FROM RawData1 
where timedate BETWEEN DATE_FORMAT(date_sub(now(),INTERVAL 2 YEAR),'%Y-%m-01') AND now(); 

2問題：

私は、同じクエリを使用していますなぜパーティション化されたテーブルが通常のテーブルより長く実行されるのですか？ 2.正規表は17.094秒で36380217を返します。それは正常です、すべてのR & Dリーダーはそれが十分に速くはないと思う、それは〜2秒で戻る必要があります。

何を確認/変更/変更する必要がありますか？ 35732495の行をスキャンし、36380217を3から4秒未満で検索するのは現実的ですか？

Answer 1

• PARTITIONingがパフォーマンス万能薬ではない理由の1つの例が見つかりました。
• idはどこから来たのですか？
• cdasiteにはいくつの値がありますか？数百万ではなく数千の場合、cdasite < => idのテーブルを作成し、かさばるVARCHAR(45)からMEDIUMINT UNSIGNED（またはそれに相当するもの）に切り替えます。この項目は最大限に役立つかもしれませんが、おそらく十分ではありません。
• statusについては、おそらくTINYINT UNSIGNEDを使用しています。 ENUMについて考えてみてください。いずれか1バイトではなく4です。
• (20)のINT(20)は何も意味しません。約2億の制限付きで4バイトの整数が得られます。
• timedatesが重複していませんか？
• branch_idとbranch_idString - これは他のテーブルにある必要があるペアのようなにおいがします。ここにはIDだけが残っていますか？
• 小さく - >高速です。
• COUNT(*)はidがNOT NULLなのでCOUNT(id)と同じです。
• 必要になる前に将来のパーティションを含めないでください。物事が遅くなる。 （パーティション化はまったく使用しないでください）

さらに高速にクエリを取得するには、サマリテーブルを作成して維持します。これは、PRIMARY KEYに少なくともDATE、そして列に少なくともCOUNT(*)を持ちます。次に、そのテーブルからクエリがフェッチされます。サマリーテーブルの詳細：http://mysql.rjweb.org/doc.php/summarytables