Depende de hasta qué punto el tamaño de las filas en la tabla particionada es la razón por la que las particiones son necesarias.
Si el tamaño de la fila es pequeño y el motivo de la partición es el gran número de filas, entonces no estoy seguro de lo que debe hacer.
Si el tamaño de la fila es bastante grande, ¿ha considerado lo siguiente?:
Sea P ser la tabla particionada y F sea la tabla a la que se hace referencia en la posible clave externa. Crear una nueva tabla 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
y, lo que es más importante, cree un procedimiento almacenado para agregar filas a la tabla P . Su procedimiento almacenado debe asegurarse (usar transacciones) de que siempre que se agregue una fila a la tabla P , se agrega una fila correspondiente a la tabla X . No debe permitir que se agreguen filas a P de la manera "normal"! Solo puede garantizar que se mantendrá la integridad referencial si continúa usando su procedimiento almacenado para agregar filas. Puede eliminar libremente desde P aunque de la manera normal.
La idea aquí es que su tabla X tiene filas lo suficientemente pequeñas como para que no sea necesario particionarlo, aunque tenga muchas filas. No obstante, el índice de la tabla ocupará una gran cantidad de memoria, supongo.
Si necesita consultar P en la clave externa, por supuesto consultará X en cambio, ya que ahí es donde realmente está la clave externa.
