Läs:MySQL-partitioneringsbegränsningar
1.) FK:er stöds inte på partitionerade tabeller.
- Ett alternativ är att skapa en lagrad procedur som infogar/uppdaterar posten och att verifiera inuti proceduren att användar-ID:t finns i din användartabell innan infogningen sker. Du bör ställa in behörigheterna på bordet så att endast SP tillåts uppdatera och infoga för att tillåta applikationer och/eller användare att gå tillbaka till kontrollen. Du måste också vidta försiktighetsåtgärder när du tar bort användare från användartabellen.
2.) Vilken kolumn du använder för partitionering beror på hur du kommer åt tabellen. Om dina frågor alltid är baserade på fordonsnummer, är det förmodligen vettigt att göra en hash-partition på den kolumnen. Om du frågar eller rapporterar mer om något som "vilka fordon har lagts till den här månaden" eller om du vill "rulla ut" partitioner när de blir en viss ålder, kan partitionering på datum vara rätt väg att gå. Detta är något du måste bestämma utifrån din användning.
3.) Se länken ovan för mer information.
Redigera baserat på användarens fråga:
Att infoga en post var tredje sekund är inte mycket genomströmning. Se till att du har en primärnyckel på din användartabell för att kontrollen i proceduren ska kunna göras effektivt. (Detta är sant även om FKs stöddes) DB skulle göra den här kontrollen för dig bakom kulisserna om du hade stöd för FK:s så i den meningen skadar det dig inte. Om kontrollen slutar som en flaskhals kan du känna ett behov av att släppa den och eventuellt rapportera felaktiga användar-ID som en nattlig batchprocess, men om din användartabell är relativt liten och korrekt indexerad ser jag inte att detta är en problem.
Ett annat alternativ skulle vara att göra partitioneringen manuellt (d.v.s. sönderdelning) med partitionerade eller icke-partitionerade tabeller. Med de icke-partitionerade tabellerna kan du naturligtvis använda inbyggda främmande nycklar. Till exempel skulle du dela upp din fordonstabell i flera tabeller som:(förutsatt att du vill använda fordonsnumret som "nyckel")
FordonInte mindre än 1000
FordonInte mindre än 2000
FordonNosLessThan...
FordonNosLessThanMAX
Här vill du förmodligen ha en SP igen så att applikationen/användaren inte behöver känna till tabellerna. SP skulle ansvara för att infoga/uppdatera rätt tabell baserat på fordonsnummer som skickats in. Du skulle också vilja ha en SP för att välja data så att appen/användaren inte behöver känna till tabellen att välja från heller. För enkel åtkomst till all data kan du skapa en vy som sammanför alla tabeller.
Observera att en fördel med detta är att MyISAM för närvarande låser en hel partitionerad tabell under uppdateringar, inte bara partitionen som den uppdaterar. Att dela en tabell på det här sättet lindrar det påståendet eftersom tabellerna själva är "partitionerna".
Baserat på den begränsade data jag har om vad du gör, skulle jag förmodligen skriva 2 lagrade procedurer, 1 för att välja data och 1 för att uppdatera/infoga data och låta din applikation använda dem för all åtkomst. Sedan skulle jag prova den vanliga partitioneringen via hash på vehicleNo först samtidigt som jag upprätthåller user_id-nyckeln inom proceduren. Om detta blir ett problem kan du enkelt migrera till att dela data över flera tabeller utan att behöva ändra applikationen eftersom all logik om hur man hämtar och uppdaterar data finns i SP:erna.