Depende da extensão em que o tamanho das linhas na tabela particionada é o motivo para as partições serem necessárias.
Se o tamanho da linha for pequeno e o motivo do particionamento for o número absoluto de linhas, então não tenho certeza do que você deve fazer.
Se o tamanho da linha for muito grande, você considerou o seguinte:
Deixe
P seja a tabela particionada e F ser a tabela referenciada na suposta chave estrangeira. Crie uma nova tabela 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, crucialmente, crie um procedimento armazenado para adicionar linhas à tabela
P . Seu procedimento armazenado deve garantir (usar transações) que sempre que uma linha for adicionada à tabela P , uma linha correspondente é adicionada à tabela X . Você não deve permitir que linhas sejam adicionadas a P da maneira "normal"! Você só pode garantir que a integridade referencial será mantida se continuar usando seu procedimento armazenado para adicionar linhas. Você pode excluir livremente de P da maneira normal, no entanto. A ideia aqui é que sua tabela
X tem linhas suficientemente pequenas para que você não precise particioná-lo, mesmo que tenha muitas linhas. O índice na tabela, no entanto, ocupará uma grande quantidade de memória, eu acho. Se você precisar consultar
P na chave estrangeira, é claro que você consultará X em vez disso, pois é onde a chave estrangeira realmente está. 
