3

約 40,000 の企業の毎週の閲覧統計を格納するテーブルがあります。テーブルは 220 万件のレコードを通過し、速度が低下し始めています。速度を上げるために分割することを検討していますが、どのように行うのが最善かわかりません。

私の ORM は主キーとして id フィールドを必要としますが、そのフィールドはデータとは関係ありません。年、週番号、およびビジネス ID のフィールドに一意のインデックスを使用しています。

パーティションマップに主キーを含める必要があるため、これをどのように整理するのが最善かわかりません (以前にパーティション分割を使用したことがありません)。

現在、私は...

    CREATE TABLE `weekly_views` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `business_id` int(11) NOT NULL,
    `year` smallint(4) UNSIGNED NOT NULL,
    `week` tinyint(2) UNSIGNED NOT NULL,
    `hits` int(5) NOT NULL,
    `created` timestamp NOT NULL ON UPDATE CURRENT_TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    `updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
    UNIQUE `search` USING BTREE (business_id, `year`, `week`),
    UNIQUE `id` USING BTREE (id, `week`)
) ENGINE=`InnoDB` AUTO_INCREMENT=2287009 DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ROW_FORMAT=COMPACT CHECKSUM=0 DELAY_KEY_WRITE=0 PARTITION BY LIST(week) PARTITIONS 52 (PARTITION p1 VALUES IN (1) ENGINE = InnoDB,
 PARTITION p2 VALUES IN (2) ENGINE = InnoDB,
 PARTITION p3 VALUES IN (3) ENGINE = InnoDB,
 PARTITION p4 VALUES IN (4) ENGINE = InnoDB,
(5 ... 51)
 PARTITION p52 VALUES IN (52) ENGINE = InnoDB);

週に 1 つのパーティションが、それらを分割する唯一の論理的な方法のように思われました。「business_id = xx and week = xx and year = xx」を使用して現在の週/ビジネスのレコードを検索すると、すべてを検索しなくても使用するパーティションがわかります。しかし、結果を取得してORM経由で保存すると、idフィールドが使用され、使用するパーティションがわからないのですか?

カスタムクエリを使用して挿入または更新できると思います（ORMがサポートしていないため、最初はこれを行っていません）。

私はこれについて正しい道を進んでいますか、それともこのようなテーブルを分割するためのより良い方法はありますか?

ご協力いただきありがとうございます！

4

1 に答える 1