Itu tergantung pada sejauh mana ukuran baris dalam tabel yang dipartisi menjadi alasan mengapa partisi diperlukan.
Jika ukuran baris kecil dan alasan untuk mempartisi adalah angka tipis baris, maka saya tidak yakin apa yang harus Anda lakukan.
Jika ukuran baris cukup besar, apakah Anda sudah mempertimbangkan hal berikut:
Biarkan P menjadi tabel yang dipartisi dan F menjadi tabel yang dirujuk dalam calon kunci asing. Buat tabel baru 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
dan yang terpenting, buat prosedur tersimpan untuk menambahkan baris ke tabel P . Prosedur tersimpan Anda harus memastikan (menggunakan transaksi) bahwa setiap kali baris ditambahkan ke tabel P , baris yang sesuai ditambahkan ke tabel X . Anda tidak boleh mengizinkan baris ditambahkan ke P dengan cara "biasa"! Anda hanya dapat menjamin bahwa integritas referensial akan dipertahankan jika Anda tetap menggunakan prosedur tersimpan untuk menambahkan baris. Anda dapat dengan bebas menghapus dari P dengan cara biasa.
Idenya di sini adalah bahwa tabel Anda X memiliki baris yang cukup kecil sehingga Anda diharapkan tidak perlu mempartisinya, meskipun memiliki banyak baris. Namun indeks di atas meja akan memakan banyak memori, saya kira.
Jika Anda perlu menanyakan P pada kunci asing, Anda tentu saja akan menanyakan X sebagai gantinya, karena di situlah letak kunci asing sebenarnya.
