Przeczytaj:Ograniczenia partycjonowania MySQL
1.) FK nie są obsługiwane w tabelach podzielonych na partycje.
- Jedną z opcji jest utworzenie procedury składowanej, która wstawia/aktualizuje rekord i sprawdza wewnątrz procedury, czy przekazany identyfikator użytkownika jest obecny w tabeli użytkowników przed wykonaniem wstawiania. Powinieneś ustawić uprawnienia w tabeli tak, aby tylko SP mógł aktualizować i wstawiać, aby umożliwić aplikacjom i/lub użytkownikom dostęp do sprawdzania backdoorem. Będziesz także musiał podjąć środki ostrożności podczas usuwania użytkowników z tabeli użytkowników.
2.) Która kolumna, której użyjesz do partycjonowania, będzie zależeć od tego, w jaki sposób uzyskujesz dostęp do tabeli. Jeśli twoje zapytania są zawsze oparte na numerze pojazdu, prawdopodobnie warto zrobić partycję mieszającą w tej kolumnie. Jeśli pytasz lub zgłaszasz więcej informacji w rodzaju „jakie pojazdy zostały dodane w tym miesiącu” lub chcesz „rozpocząć” partycje, gdy osiągną określony wiek, najlepszym rozwiązaniem może być podział na daną datę. To jest coś, co musisz zdecydować na podstawie swojego użytkowania.
3.) Zobacz powyższy link, aby uzyskać więcej informacji.
Edytuj na podstawie pytania użytkownika:
Wstawianie rekordu co 3 sekundy nie jest dużą przepustowością. Upewnij się, że masz klucz podstawowy w tabeli użytkowników, aby kontrola wewnątrz procedury była wykonywana skutecznie. (To prawda, nawet jeśli FK byłyby wspierane) DB wykonałby dla ciebie ten test za kulisami, gdybyś miał wsparcie dla FK, więc w tym sensie, to ci nie szkodzi. Jeśli kontrola okaże się wąskim gardłem, możesz czuć potrzebę jej porzucenia i prawdopodobnie zgłoszenia błędnych identyfikatorów użytkowników jako conocnego procesu wsadowego, ale jeśli Twoja tabela użytkowników jest stosunkowo mała i poprawnie zindeksowana, nie widzę tego jako problem.
Inną opcją byłoby ręczne partycjonowanie (tj. sharding) z partycjonowanymi lub niepartycjonowanymi tabelami. W przypadku tabel niepartycjonowanych można oczywiście używać natywnych kluczy obcych. Na przykład możesz podzielić tabelę pojazdów na wiele tabel, takich jak:(zakładając, że chcesz użyć pojazdu jako "klucza")
PojazdyNosLessThan1000
PojazdyNosLessThan2000
PojazdyNosLessThan...
PojazdyNosLessThanMAX
Tutaj prawdopodobnie chcesz ponownie mieć SP, aby aplikacja/użytkownik nie musiał wiedzieć o tabelach. Dostawca usług będzie odpowiedzialny za wstawianie/aktualizowanie prawidłowej tabeli na podstawie przekazanego numeru pojazdu. Potrzebujesz również dostawcy usług do wybierania danych, aby aplikacja/użytkownik nie musiał znać tabeli, z której może dokonać wyboru. Aby uzyskać łatwy dostęp do wszystkich danych, możesz utworzyć widok, który łączy wszystkie tabele razem.
Zauważ, że jedną z zalet tego jest to, że obecnie MyISAM blokuje całą partycjonowaną tabelę podczas aktualizacji, a nie tylko aktualizowaną partycję. Dzielenie tabeli w ten sposób łagodzi tę rywalizację, ponieważ same tabele są „partycjami”.
W oparciu o ograniczone dane, które mam na temat tego, co robisz, prawdopodobnie napisałbym 2 procedury składowane, 1 do wybierania danych i 1 do aktualizowania/wstawiania danych, a Twoja aplikacja używa ich do pełnego dostępu. Następnie spróbowałbym najpierw przeprowadzić regularne partycjonowanie za pomocą skrótu na vehicleNo podczas wymuszania klucza user_id w ramach procedury. Jeśli stanie się to problemem, możesz łatwo przejść na sharding danych w wielu tabelach bez konieczności zmiany aplikacji, ponieważ cała logika pobierania i aktualizowania danych jest zawarta w SP.
