La taille de la table n'est pas vraiment le problème, les requêtes que vous exécutez sur cette table peuvent l'être.
Par exemple, si vous sélectionnez des utilisateurs en fonction des données stockées dans la table meta utilisateur, cette requête sera fortement non optimisée, car meta_value n'est pas un champ indexé. Dans ce cas, vous devrez peut-être ajouter des index supplémentaires ou envisager de stocker ces données particulières d'une manière différente, comme avec une taxonomie personnalisée.
De manière générale, les éléments que vous stockez en tant que méta ne devraient jamais être quelque chose sur lequel vous effectuerez une recherche exclusive. Cela s'applique à toutes les méta-tables de WordPress. La méta est principalement conçue pour être extraite par la meta_key, et non par la meta_value. Les taxonomies limitent les valeurs possibles à un ensemble et organisent les informations différemment, donc elles font mieux lorsque la "valeur" compte comme ce que vous sélectionnez.
Remarque, la sélection à la fois par meta_key et meta_value est généralement correcte, car mySQL optimisera la requête en fonction de la meta_key en premier, réduisant la quantité de données à rechercher à une limite (espérons-le) gérable. Si même cela devient un problème, vous pouvez le "corriger" en ajoutant un nouvel index à la méta-table avec à la fois meta_key et meta_value sur l'index, cependant parce que meta_value est LONGTEXT, vous devez limiter la longueur de cet index à quelque chose de raisonnable, comme 20-30 ou quelque chose, selon vos données. Notez que cet index peut être beaucoup, beaucoup plus grand que vos données réelles et augmentera considérablement l'espace de stockage nécessaire. Cependant, il sera beaucoup plus rapide dans ces types de requêtes. Consultez un administrateur de base de données qualifié si cela devient un problème réel.
Pour référence, sur WordPress.org, nous avons environ 11 millions d'utilisateurs enregistrés. La quantité de méta varie selon l'utilisateur, avec probablement un minimum de 8 lignes par, et peut-être un maximum d'environ 250 ish. La table des utilisateurs fait environ 2,5 Go, la table usermeta environ 4 Go. Semble fonctionner correctement, pour la plupart, mais de temps en temps, nous trouvons une requête étrange que nous devons optimiser.
(object_type,meta_key,meta_value(50))Sauf si vous exécutez vos propres requêtes au lieu d'utiliser l'API, la taille de la table n'a pas autant d'importance que wordpress exécute les requêtes par les index de la table et MYSQL censé optimiser ce type de requêtes. Chaque requête récupère également toutes les méta-informations dans une seule requête.
Si vous insistez, vous pouvez diviser la méta-table utilisateur en plusieurs tables en utilisant un hachage sur l'ID utilisateur comme nom de table, mais vous devrez probablement écrire un remplacement dans la classe wp_db pour accéder à la bonne table en fonction de la requête. Si vous êtes intéressé à suivre ce chemin, recherchez des solutions pour gérer les grandes installations réseau avec de nombreux blogs.
Mais si vous n'avez pas de problèmes de performances maintenant, vous pouvez vous développer beaucoup plus sans effectuer d'ajustement significatif. Lorsque vous commencez à obtenir des problèmes de performances, déplacez simplement la base de données vers un serveur plus rapide, il sera plus rentable que toute manipulation que vous pouvez faire de la façon dont WP accède à ces informations.
la source