Lesen Sie:Einschränkungen bei der MySQL-Partitionierung
1.) FKs werden auf partitionierten Tabellen nicht unterstützt.
- Eine Option besteht darin, eine gespeicherte Prozedur zu erstellen, die den Datensatz einfügt/aktualisiert, und innerhalb der Prozedur zu überprüfen, ob die übergebene Benutzer-ID in Ihrer Benutzertabelle vorhanden ist, bevor die Einfügung stattfindet. Sie sollten die Berechtigungen für die Tabelle so einrichten, dass nur der SP aktualisieren und einfügen darf, damit Anwendungen und/oder Benutzer die Prüfung nicht durch Backdoors durchführen können. Sie müssen auch Vorsichtsmaßnahmen treffen, wenn Sie Benutzer aus der Benutzertabelle entfernen.
2.) Welche Spalte Sie für die Partitionierung verwenden, hängt davon ab, wie Sie auf die Tabelle zugreifen. Wenn Ihre Abfragen immer auf der Fahrzeugnummer basieren, ist es wahrscheinlich sinnvoll, eine Hash-Partition für diese Spalte durchzuführen. Wenn Sie mehr über etwas wie „Welche Fahrzeuge wurden in diesem Monat hinzugefügt“ abfragen oder darüber berichten oder wenn Sie Partitionen „ausrollen“ möchten, wenn sie ein bestimmtes Alter erreichen, dann ist die Partitionierung nach Datum möglicherweise der richtige Weg. Dies müssen Sie basierend auf Ihrer Nutzung entscheiden.
3.) Weitere Informationen finden Sie unter dem obigen Link.
Bearbeiten basierend auf Benutzerfrage:
Das Einfügen eines Datensatzes alle 3 Sekunden ist nicht viel Durchsatz. Stellen Sie sicher, dass Sie einen Primärschlüssel in Ihrer Benutzertabelle haben, damit die Überprüfung innerhalb der Prozedur effizient durchgeführt werden kann. (Dies gilt auch, wenn FKs unterstützt würden) Die DB würde diese Überprüfung für Sie hinter den Kulissen durchführen, wenn Sie Unterstützung für FKs hätten, also schadet es Ihnen in diesem Sinne nicht. Wenn die Überprüfung zu einem Engpass wird, müssen Sie sie möglicherweise löschen und möglicherweise fehlerhafte Benutzer-IDs als nächtlichen Batch-Prozess melden. Wenn Ihre Benutzertabelle jedoch relativ klein und korrekt indiziert ist, sehe ich dies nicht als einen an Problem.
Eine andere Möglichkeit wäre die manuelle Partitionierung (d. h. Sharding) mit partitionierten oder nicht partitionierten Tabellen. Bei den nicht partitionierten Tabellen könnten Sie natürlich native Fremdschlüssel verwenden. Zum Beispiel würden Sie Ihre Fahrzeugtabelle in mehrere Tabellen aufteilen wie:(vorausgesetzt, Sie möchten die Fahrzeugnummer als "Schlüssel" verwenden)
VehiclesNosLessThan1000
FahrzeugeNosLessThan2000
FahrzeugeNosLessThan...
FahrzeugeNosLessThanMAX
Hier möchten Sie wahrscheinlich wieder einen SP haben, damit die Anwendung / der Benutzer nichts von den Tabellen wissen muss. Der SP wäre für das Einfügen/Aktualisieren der richtigen Tabelle basierend auf der übergebenen Fahrzeugnummer verantwortlich. Sie möchten auch einen SP zum Auswählen von Daten, damit die App/der Benutzer die Tabelle nicht kennen muss, aus der sie auswählen können. Für einfachen Zugriff auf alle Daten können Sie eine Ansicht erstellen, die alle Tabellen vereint.
Beachten Sie, dass ein Vorteil davon darin besteht, dass MyISAM derzeit eine ganze partitionierte Tabelle während Aktualisierungen sperrt, nicht nur die Partition, die es aktualisiert. Das Sharding einer Tabelle auf diese Weise mildert diesen Konflikt, da die Tabellen selbst die "Partitionen" sind.
Basierend auf den begrenzten Daten, die ich zu dem habe, was Sie tun, würde ich wahrscheinlich 2 gespeicherte Prozeduren schreiben, 1 zum Auswählen der Daten und 1 zum Aktualisieren/Einfügen der Daten, und Ihre Anwendung diese für den gesamten Zugriff verwenden lassen. Dann würde ich zuerst die reguläre Partitionierung per Hash auf vehicleNo versuchen, während ich den user_id-Schlüssel innerhalb der Prozedur erzwinge. Wenn dies zu einem Problem wird, können Sie problemlos zum Sharding der Daten über mehrere Tabellen hinweg migrieren, ohne die Anwendung ändern zu müssen, da die gesamte Logik zum Abrufen und Aktualisieren der Daten in den SPs enthalten ist.
