Comment fonctionne la partition hash (row id + year)?

Question

Je suis nouveau avec les partitions. Je ne savais pas qu'il existait, mais je me suis rendu compte quand j'ai essayé de rendre notre nouvelle colonne 'url_hash' unique dans un tableau dans notre base de données. Et a obtenu le message d'erreur:

Un index unique doit inclure toutes les colonnes dans la fonction de partitionnement de la table

Ceci est une base de données créée par une autre personne que je ne connais pas et qui ne sont pas impliqués dans le projet plus.

J'ai essayé de lire la documentation mysql et de lire sur les forums sur Partition. Qu'est-ce que c'est et comment cela fonctionne. Comprendre le but, de "diviser" une table en plusieurs "parties" de sorte qu'il devient plus rapide pour récupérer des données pertinentes. Un exemple commun est de partitionner dans des intervalles de plusieurs années. Mais la plupart des exemples montrent une méthode manuelle. Où vous décidez par exemple moins de trois années spécifiques. Par exemple:

PARTITION BY RANGE (YEAR(separated)) (
    PARTITION p0 VALUES LESS THAN (1991), 
    PARTITION p1 VALUES LESS THAN (1996), 
    PARTITION p2 VALUES LESS THAN (2001), 
    PARTITION p3 VALUES LESS THAN MAXVALUE 
); 

Mais dans notre tableau, les partitions sont créées de cette façon:

PARTITION BY HASH (`feeditemsID` + YEAR(`feeddate`)) 
PARTITIONS 3; 

Qu'est-ce que cela signifie? Comment fonctionne notre partition?

feeditemsID est l'ID unique pour chaque ligne de notre tableau.

Answer 1

Lorsque vous utilisez le partitionnement de hachage, la partition qui contient chaque enregistrement est déterminée en calculant un code de hachage à partir de l'expression feaditemsID + YEAR(feeddate), puis en recherchant le module de ce code par le nombre de partitions. Donc, si le code de hachage d'une ligne est 123, il calcule 123 % 3, ce qui correspond à 0. L'enregistrement passe donc dans la partition 0. Ceci est expliqué dans le document MySQL documentation.

Comme il a déclaré,

Remarque
Si une table à partitionner a une clé unique, puis les colonnes fournies comme arguments à la fonction utilisateur HASH ou à de column_list de la clé doit faire partie de cette clé.

Dans votre cas, l'être le tableau des besoins clé primaire:

PRIMARY KEY (feeditemsID, feeddate) 

En supposant feeditemsID est déjà unique (on peut supposer qu'il est une colonne auto-incrément), en ajoutant feeddate au primaire est redondant dans la mesure garder les données uniques est concerné, mais il est nécessaire pour satisfaire aux exigences de partitionnement. Mettre d'abord feeditemsID dans la clé composite lui permettra d'être utilisé par lui-même pour optimiser la recherche de table.

Cette exigence est probablement due au fait que chaque partition a son propre index. Lors de l'insertion/mise à jour d'une ligne et de la vérification de l'unicité, elle vérifie uniquement l'index de la partition où cette ligne sera stockée. Donc, quand il trouve la partition en utilisant la fonction de hachage, il doit s'assurer que cette partition contiendra uniquement les colonnes indexées.

Pour plus d'informations, voir

Partitioning Keys, Primary Keys, and Unique Keys