Cela dépend de la mesure dans laquelle la taille des lignes de la table partitionnée est la raison pour laquelle les partitions sont nécessaires.
Si la taille de la ligne est petite et que la raison du partitionnement est le nombre pur de lignes, alors je ne suis pas sûr de ce que vous devriez faire.
Si la taille de la ligne est assez grande, avez-vous pensé à ce qui suit :
Soit P être la table partitionnée et F être la table référencée dans la clé étrangère potentielle. Créer un nouveau tableau 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
et surtout, créez une procédure stockée pour ajouter des lignes à la table P . Votre procédure stockée doit s'assurer (utiliser des transactions) que chaque fois qu'une ligne est ajoutée à la table P , une ligne correspondante est ajoutée à la table X . Vous ne devez pas autoriser l'ajout de lignes à P de manière "normale" ! Vous ne pouvez garantir que l'intégrité référentielle sera maintenue que si vous continuez à utiliser votre procédure stockée pour ajouter des lignes. Vous pouvez librement supprimer de P de manière normale, cependant.
L'idée ici est que votre table X contient des lignes suffisamment petites pour que vous n'ayez pas besoin de le partitionner, même s'il contient de nombreuses lignes. L'index sur la table occupera néanmoins une assez grande partie de la mémoire, je suppose.
Si vous avez besoin d'interroger P sur la clé étrangère, vous interrogerez bien sûr X à la place, car c'est là que se trouve réellement la clé étrangère.
