Lisez :Limitations du partitionnement MySQL
1.) Les FK ne sont pas pris en charge sur les tables partitionnées.
- Une option consiste à créer une procédure stockée qui insère/met à jour l'enregistrement et à vérifier dans la procédure que l'ID utilisateur passé est présent dans votre table d'utilisateurs avant que l'insertion n'ait lieu. Vous devez configurer les autorisations sur le tableau afin que seul le SP soit autorisé à mettre à jour et à insérer pour permettre aux applications et/ou aux utilisateurs de détourner la vérification. Vous devrez également prendre des précautions lors de la suppression d'utilisateurs du tableau des utilisateurs.
2.) La colonne que vous utilisez pour le partitionnement dépendra de la façon dont vous accédez à la table. Si vos requêtes sont toujours basées sur le numéro de véhicule, il est probablement logique de faire une partition de hachage sur cette colonne. Si vous interrogez ou rapportez davantage sur quelque chose comme "quels véhicules ont été ajoutés ce mois-ci" ou si vous souhaitez "déployer" les partitions à mesure qu'elles atteignent un certain âge, alors le partitionnement à la date peut être la solution. C'est quelque chose que vous devrez décider en fonction de votre utilisation.
3.) Voir le lien ci-dessus pour plus d'informations.
Modifier en fonction de la question de l'utilisateur :
L'insertion d'un enregistrement toutes les 3 secondes n'est pas beaucoup de débit. Assurez-vous d'avoir une clé primaire sur votre table d'utilisateurs afin que la vérification à l'intérieur de la procédure soit effectuée efficacement. (Ceci est vrai même si les FK étaient pris en charge) La base de données ferait cette vérification pour vous dans les coulisses si vous aviez un support pour les FK, donc dans ce sens, cela ne vous fait pas de mal. Si la vérification finit par être un goulot d'étranglement, vous ressentirez peut-être le besoin de la supprimer et éventuellement de signaler des identifiants d'utilisateur errants en tant que processus par lots nocturne, mais si votre table utilisateur est relativement petite et indexée correctement, je ne vois pas cela être un problème.
Une autre option consisterait à effectuer le partitionnement manuellement (c'est-à-dire le partitionnement) avec des tables partitionnées ou non partitionnées. Avec les tables non partitionnées, vous pouvez bien sûr utiliser des clés étrangères natives. Par exemple, vous diviseriez votre table de véhicules en plusieurs tables comme :(en supposant que vous souhaitiez utiliser le numéro de véhicule comme "clé")
VéhiculesNosLessThan1000
VéhiculesNosLessThan2000
VéhiculesNosLessThan...
VéhiculesNosLessThanMAX
Ici, vous voudrez probablement avoir à nouveau un SP afin que l'application/l'utilisateur n'ait pas à connaître les tables. Le SP serait responsable de l'insertion/de la mise à jour de la table correcte en fonction du numéro de véhicule transmis. Vous voudriez également un SP pour sélectionner des données afin que l'application/l'utilisateur n'ait pas à connaître la table à sélectionner. Pour un accès facile à toutes les données, vous pouvez créer une vue qui regroupe toutes les tables.
Notez que l'un des avantages de ceci est qu'actuellement MyISAM verrouille une table partitionnée entière pendant les mises à jour, pas seulement la partition qu'elle met à jour. Partager une table de cette manière atténue ce conflit, car les tables elles-mêmes sont les "partitions".
Sur la base des données limitées dont je dispose sur ce que vous faites, j'écrirais probablement 2 procédures stockées, 1 pour sélectionner les données et 1 pour mettre à jour/insérer les données et faire en sorte que votre application les utilise pour tous les accès. Ensuite, j'essaierais d'abord le partitionnement régulier via le hachage sur vehicleNo tout en appliquant la clé user_id dans la procédure. Si cela devient un problème, vous pouvez facilement migrer vers le partage des données sur plusieurs tables sans avoir à modifier l'application car toute la logique sur la façon de récupérer et de mettre à jour les données est contenue dans les SP.
