Dipende dalla misura in cui la dimensione delle righe nella tabella partizionata è il motivo per cui le partizioni sono necessarie.
Se la dimensione della riga è piccola e il motivo del partizionamento è il numero assoluto di righe, quindi non sono sicuro di cosa dovresti fare.
Se la dimensione della riga è abbastanza grande, hai considerato quanto segue:
Sia P essere la tabella partizionata e F essere la tabella a cui si fa riferimento nella presunta chiave esterna. Crea una nuova tabella 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
e soprattutto, creare una procedura memorizzata per aggiungere righe alla tabella P . La tua procedura memorizzata dovrebbe accertarsi (usare le transazioni) che ogni volta che una riga viene aggiunta alla tabella P , viene aggiunta una riga corrispondente alla tabella X . Non devi consentire l'aggiunta di righe a P nel modo "normale"! È possibile garantire il mantenimento dell'integrità referenziale solo se si continua a utilizzare la stored procedure per l'aggiunta di righe. Puoi cancellare liberamente da P nel modo normale, però.
L'idea qui è che la tua tabella X ha righe sufficientemente piccole che si spera non sia necessario partizionarlo, anche se ha molte molte righe. L'indice sul tavolo occuperà comunque una grossa fetta di memoria, suppongo.
Se hai bisogno di interrogare P sulla chiave esterna, ovviamente interrogherai X invece, poiché è lì che si trova effettivamente la chiave esterna.
