Прочетете:Ограничения за разделяне на MySQL
1.) FK не се поддържат в разделени таблици.
- Една от опциите е да създадете съхранена процедура, която вмъква/актуализира записа и да провери вътре в процедурата, че преданият потребителски идентификатор присъства във вашата таблица с потребители, преди да се осъществи вмъкването. Трябва да настроите разрешенията в таблицата, така че само SP да има право да актуализира и вмъква, за да позволи на приложения и/или потребители да правят бекдор проверката. Също така ще трябва да вземете предпазни мерки, когато премахвате потребители от таблицата с потребители.
2.) Коя колона ще използвате за разделяне ще зависи от начина, по който осъществявате достъп до таблицата. Ако вашите заявки винаги се базират на номер на превозно средство, тогава вероятно има смисъл да направите хеш дял в тази колона. Ако питате или отчитате повече за нещо като „какви превозни средства са добавени този месец“ или искате да „развиете“ дялове, когато станат на определена възраст, тогава разделянето по дата може да е начинът. Това е нещо, което ще трябва да решите въз основа на вашето използване.
3.) Вижте връзката по-горе за повече информация.
Редактиране въз основа на потребителски въпрос:
Вмъкването на запис на всеки 3 секунди не е голяма пропускателна способност. Уверете се, че имате първичен ключ във вашата таблица с потребители, за да може проверката в процедурата да се извърши ефективно. (Това е вярно, дори ако се поддържаха FK) DB щеше да направи тази проверка вместо вас зад кулисите, ако имате поддръжка за FK, така че в този смисъл това не ви наранява. Ако проверката в крайна сметка се окаже пречка, може да почувствате необходимостта да я изоставите и евентуално да докладвате за грешни потребителски идентификатори като еженощен пакетен процес, но ако потребителската ви таблица е сравнително малка и индексирана правилно, не виждам, че това е проблем.
Друг вариант би бил да направите разделянето ръчно (т.е. разделяне) с разделени или неразделени таблици. С неразделените таблици, разбира се, можете да използвате собствени външни ключове. Например бихте разделили таблицата си с превозни средства на няколко таблици като:(ако приемем, че искате да използвате номер на превозното средство като „ключ“)
Превозни средства NosLessThan1000
Превозни средства NosLessThan2000
Превозни средстваNosLessThan...
Превозни средства NosLessThanMAX
Тук вероятно искате отново да имате SP, така че приложението/потребителят да не знае за таблиците. SP ще бъде отговорен за вмъкването/актуализирането на правилната таблица въз основа на подаденото превозно средствоNo. Вие също бихте искали SP за избор на данни, така че приложението/потребителят да не трябва да знае таблицата, от която да избира. За лесен достъп до всички данни можете да създадете изглед, който обединява всички таблици заедно.
Имайте предвид, че едно предимство от това е, че в момента MyISAM заключва цяла разделена таблица по време на актуализации, а не само дяла, който актуализира. Разделянето на таблица по този начин облекчава това противоречие, тъй като самите таблици са „раздели“.
Въз основа на ограничените данни, които имам за това, което правите, вероятно ще напиша 2 съхранени процедури, 1 за избор на данни и 1 за актуализиране/вмъкване на данните и вашето приложение да ги използва за пълен достъп. След това бих опитал обикновеното разделяне чрез хеш на vehicleNo първо, докато налагам ключа user_id в рамките на процедурата. Ако това стане проблем, можете лесно да мигрирате към споделяне на данните в множество таблици, без да се налага да променяте приложението, тъй като цялата логика за извличане и актуализиране на данните се съдържа в SP.
