Partitionera mySQL-tabeller som har främmande nycklar?

Det beror på i vilken utsträckning storleken på raderna i den partitionerade tabellen är anledningen till att partitioner är nödvändiga.

Om radstorleken är liten och anledningen till partitionering är det rena numret rader, då är jag inte säker på vad du ska göra.

Om radstorleken är ganska stor, har du då tänkt på följande:

Låt P vara den partitionerade tabellen och F vara tabellen som refereras till i den potentiella främmande nyckeln. Skapa en ny tabell 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

och avgörande, skapa en lagrad procedur för att lägga till rader i tabellen P . Din lagrade procedur bör säkerställa (använd transaktioner) att när en rad läggs till i tabellen P , läggs en motsvarande rad till i tabellen X . Du får inte tillåta att rader läggs till i P på "normalt" sätt! Du kan bara garantera att referensintegriteten bibehålls om du fortsätter att använda din lagrade procedur för att lägga till rader. Du kan fritt radera från P på normalt sätt dock.

Tanken här är att din tabell X har tillräckligt små rader för att du förhoppningsvis inte ska behöva partitionera den, även om den har många många rader. Indexet på bordet kommer ändå att ta upp en ganska stor del av minnet, antar jag.

Om du behöver fråga P på den främmande nyckeln kommer du naturligtvis att fråga X istället, eftersom det är där den främmande nyckeln faktiskt finns.