5

mySQLは明らかにこれを楽しんでいないので、これを行う適切な方法は何でしょうか。データベース設計からパーティショニングまたは外部キーを除外することは、私には良い考えとは思えません。これには回避策があると思いますか？

更新 03/24:

http://opendba.blogspot.com/2008/10/mysql-partitioned-tables-with-trigger.html

パーティショニング中に外部キーを処理する方法

ありがとう！

4

2 に答える 2

2

これは、パーティション化されたテーブルの行のサイズが、パーティションが必要になる理由の程度によって異なります。

行サイズが小さく、パーティショニングの理由が膨大な数の行である場合、どうすればよいかわかりません。

行サイズが非常に大きい場合は、次のことを考慮しましたか?

をパーティション化されたPテーブルとFし、外部キーで参照されるテーブルとします。新しいテーブルを作成しますX:

CREATE TABLE `X` (
    `P_id` INT UNSIGNED NOT NULL,
        -- I'm assuming an INT is adequate, but perhaps
        -- you will actually require a BIGINT
    `F_id` INT UNSIGNED NOT NULL,
    PRIMARY KEY (`P_id`, `F_id`),
    CONSTRAINT `Constr_X_P_fk`
        FOREIGN KEY `P_fk` (`P_id`) REFERENCES `P`.`id`
        ON DELETE CASCADE ON UPDATE RESTRICT,
    CONSTRAINT `Constr_X_F_fk`
        FOREIGN KEY `F_fk` (`F_id`) REFERENCES `F`.`id`
        ON DELETE RESTRICT ON UPDATE RESTRICT
) ENGINE=INNODB CHARACTER SET ascii COLLATE ascii_general_ci

そして決定的に、 table に行を追加するためのストアド プロシージャを作成しますP。ストアド プロシージャは、 table に行が追加されるたびPに、対応する行がtable に追加されることを確認する (トランザクションを使用する) 必要がありますX。P「通常の」方法で行を追加することを許可してはなりません! ストアド プロシージャを使用して行を追加し続ける場合にのみ、参照整合性が維持されることを保証できます。Pただし、通常の方法でから自由に削除できます。

ここでの考え方は、テーブルXに多数の行が含まれていても、パーティション化する必要がないほど十分に小さい行があるということです。それにもかかわらず、テーブルのインデックスはかなりの量のメモリを占有すると思います。

外部キーを照会する必要がある場合は、外部キーが実際にある場所であるため、PもちろんX代わりに照会します。

于 2010-06-04T15:24:19.413 に答える
2

データをアーカイブ テーブルにアーカイブするためのキーとして Date を使用してシャーディングすることを強くお勧めします。複数のアーカイブ テーブルからレポートする必要がある場合は、ビューを使用するか、ロジックをアプリケーションに組み込むことができます。

ただし、適切に構造化された DB を使用すると、パーティション化する前に、またはシャーディングが実際に必要になる前に、テーブル内の数千万行を処理できるはずです。

于 2010-06-01T20:30:06.800 に答える