Это зависит от степени, в которой размер строк в многораздельной таблице является причиной необходимости разбиения.
Если размер строки небольшой и причиной разделения является число строк, то я не уверен, что вам следует делать.
Если размер строки достаточно велик, учитывайте ли вы следующее:
Пусть P будет секционированной таблицей, а F будет таблицей, на которую ссылается потенциальный внешний ключ. Создать новую таблицу 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
и, что особенно важно, создайте хранимую процедуру для добавления строк в таблицу P. Ваша хранимая процедура должна убедиться (использовать транзакции), что всякий раз, когда строка добавляется в таблицу P, соответствующая строка добавляется в таблицу X. Вы не должны допускать, чтобы строки добавлялись к P "обычным" способом! Вы можете гарантировать сохранение ссылочной целостности только в том случае, если вы продолжаете использовать свою хранимую процедуру для добавления строк. Вы можете свободно удалить из P обычным способом.
Идея в том, что ваша таблица X имеет достаточно маленькие строки, поэтому, надеюсь, вам не нужно разбивать ее, даже если в ней много много строк. Я полагаю, что индекс таблицы будет занимать довольно большой кусок памяти.
Если вам нужно запросить P по внешнему ключу, вы, конечно, вместо этого запросите X, поскольку именно там находится внешний ключ.