Læs:MySQL-partitioneringsbegrænsninger
1.) FK'er understøttes ikke på partitionerede tabeller.
- En mulighed er at oprette en lagret procedure, der indsætter/opdaterer posten, og at kontrollere inde i proceduren, at det beståede bruger-id er til stede i din brugertabel, før indsættelsen finder sted. Du bør konfigurere tilladelserne på bordet, så kun SP har tilladelse til at opdatere og indsætte for at tillade applikationer og/eller brugere at gå tilbage til kontrollen. Du skal også tage forholdsregler, når du fjerner brugere fra brugertabellen.
2.) Hvilken kolonne du bruger til partitionering vil afhænge af hvordan du får adgang til tabellen. Hvis dine forespørgsler altid er baseret på vechicle nr., så giver det sandsynligvis mening at lave en hash-partition på den kolonne. Hvis du forespørger eller rapporterer mere om noget som "hvilke køretøjer er blevet tilføjet i denne måned", eller du vil "rulle" partitioner ud, når de bliver en vis alder, så kan partitionering på dato være vejen at gå. Dette er noget, du skal beslutte ud fra dit forbrug.
3.) Se linket ovenfor for mere information.
Rediger baseret på brugerspørgsmål:
At indsætte en post hvert 3. sekund er ikke meget gennemløb. Sørg for, at du har en primær nøgle på dit brugerbord, for at kontrollen i proceduren kan udføres effektivt. (Dette er sandt, selvom FK'er blev understøttet) DB ville lave denne check for dig bag kulisserne, hvis du havde støtte til FK'er, så i den forstand skader det dig ikke. Hvis kontrollen ender med at blive en flaskehals, kan du føle behov for at droppe den og muligvis rapportere fejlagtige bruger-id'er som en natlig batch-proces, men hvis din brugertabel er relativt lille og indekseret korrekt, kan jeg ikke se, at dette er en problem.
En anden mulighed ville være at udføre partitioneringen manuelt (dvs. sharding) med partitionerede eller ikke-partitionerede tabeller. Med de ikke-opdelte tabeller kan du selvfølgelig bruge native fremmednøgler. For eksempel vil du opdele din køretøjstabel i flere tabeller som:(forudsat at du vil bruge køretøjsnummeret som "nøgle")
Køretøjer ikke mindre end 1000
Køretøjer ikke mindre end 2000
KøretøjerNosLessThan...
KøretøjerNosLessThanMAX
Her vil du sikkert gerne have en SP igen, så applikationen/brugeren ikke skal kende til tabellerne. SP'en ville være ansvarlig for at indsætte/opdatere den korrekte tabel baseret på det indsendte køretøjsnummer. Du vil også have en SP til at udvælge data, så app'en/brugeren heller ikke behøver at kende tabellen til at vælge fra. For nem adgang til alle data kan du oprette en visning, der samler alle tabellerne.
Bemærk, at en fordel ved dette er, at MyISAM i øjeblikket låser en hel opdelt tabel under opdateringer, ikke kun den partition, den opdaterer. At dele en tabel på denne måde afhjælper den strid, fordi tabellerne selv er "partitionerne".
Baseret på de begrænsede data, jeg har om, hvad du laver, ville jeg nok skrive 2 lagrede procedurer, 1 til valg af data og 1 til opdatering/indsættelse af data og få din applikation til at bruge dem til al adgang. Så ville jeg prøve den almindelige partitionering via hash på vehicleNo først, mens jeg håndhævede user_id-nøglen i proceduren. Hvis dette bliver et problem, kan du nemt migrere til at dele data på tværs af flere tabeller, uden at du behøver at ændre applikationen, fordi al logikken om, hvordan du henter og opdaterer dataene, er indeholdt i SP'erne.