Partitionering af mySQL-tabeller, der har fremmednøgler?

Det afhænger af, i hvilket omfang størrelsen af ​​rækker i den opdelte tabel er årsagen til, at partitioner er nødvendige.

Hvis rækkestørrelsen er lille, og årsagen til partitionering er tallet rækker, så er jeg ikke sikker på, hvad du skal gøre.

Hvis rækkestørrelsen er ret stor, har du så overvejet følgende:

Lad P være den opdelte tabel og F være den tabel, der henvises til i den potentielle fremmednøgle. Opret en ny tabel 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

og afgørende, opret en lagret procedure for tilføjelse af rækker til tabel P . Din lagrede procedure skal sikre (brug transaktioner), at når en række tilføjes til tabel P , tilføjes en tilsvarende række til tabel X . Du må ikke tillade, at rækker tilføjes til P på den "normale" måde! Du kan kun garantere, at referenceintegriteten bevares, hvis du fortsætter med at bruge din lagrede procedure til tilføjelse af rækker. Du kan frit slette fra P dog på normal vis.

Ideen her er, at din tabel X har tilstrækkeligt små rækker til, at du forhåbentlig ikke behøver at partitionere den, selvom den har mange mange rækker. Indekset på bordet vil ikke desto mindre fylde en stor del af hukommelsen, tror jeg.

Hvis du har brug for at forespørge P på fremmednøglen vil du naturligvis spørge X i stedet, da det er der fremmednøglen faktisk er.