Zależy to od tego, w jakim stopniu rozmiar wierszy w tabeli partycjonowanej jest przyczyną konieczności partycjonowania.
Jeśli rozmiar wiersza jest mały, a powodem partycjonowania jest zwykła liczba rzędów, to nie jestem pewien, co powinieneś zrobić.
Jeśli rozmiar wiersza jest dość duży, czy rozważyłeś następujące kwestie:
Niech P być tabelą partycjonowaną i F być tabelą, do której odwołuje się niedoszły klucz obcy. Utwórz nową tabelę 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
i co najważniejsze, utwórz procedurę składowaną do dodawania wierszy do tabeli P . Twoja procedura składowana powinna zapewniać (używać transakcji), że za każdym razem, gdy wiersz jest dodawany do tabeli P , odpowiedni wiersz zostanie dodany do tabeli X . Nie możesz pozwolić na dodawanie wierszy do P w „normalny” sposób! Możesz zagwarantować, że integralność referencyjna zostanie zachowana, jeśli będziesz nadal używać procedury składowanej do dodawania wierszy. Możesz swobodnie usuwać z P w normalny sposób.
Pomysł polega na tym, że twoja tabela X ma na tyle małe wiersze, że miejmy nadzieję, że nie trzeba go dzielić na partycje, mimo że ma wiele wierszy. Indeks w tabeli zajmie jednak całkiem spory kawałek pamięci, jak sądzę.
Jeśli potrzebujesz zapytać P na kluczu obcym, oczywiście zapytasz X zamiast tego, ponieważ tam właśnie znajduje się klucz obcy.
