Réponses:
En général, plus vous disposez de tout ce qui réduit les performances. Cependant, 200 semble être un nombre assez petit. 2000 pourrait être un vrai coup de performance et certainement 20 000. En général, cependant, vous devriez garder votre nombre de tables petit car MySQL peut gérer un très grand nombre de lignes dans la table.
Le nombre de tables importe peu:
Avoir des tables en excès signifie de la mémoire et de l'espace sur le disque dur qui pourraient être récupérés et utilisés pour d'autres choses. Gardez à l'esprit que la dénormalisation de vos tables augmente le risque de mauvaises données car vous vous débarrassez de l'intégrité référentielle.
En général, 200 tableaux ne devraient pas être un problème, mais cela dépend d'un certain nombre de choses.
Serveur MySQL dédié vs serveur partagé avec d'autres logiciels, 128 Mo vs 128 Go de RAM, etc., petites tables avec peu d'enregistrements vs tables avec des blobs et des millions de lignes.
MySQL a plusieurs paramètres et plusieurs moteurs affectant chacun les performances des tables de différentes manières.
MyISAM a normalement trois fichiers par table .frm, .MYD, .MYI
INNODB en mode normal a .frm avec toutes les données stockées dans le fichier central
INNODB dans un fichier par mode table a .frm, .idb
table_open_cache est le nombre de tables pouvant être ouvertes simultanément (64 par défaut). Cela peut être supérieur au nombre de tables de votre schéma car il est lié au nombre de connexions interrogeant la base de données. 100 connexions joignent 3 tables pourraient signifier que vous avez 300 tables mises en cache plus toutes les tables temporaires. Généralement, un schéma ou des connexions sont plus complexes, plus le nombre est élevé.
open-files-limit J'ai tendance à définir cela à 4x table_open_cache qui devrait être généreux plutôt que de se soucier de trouver une valeur exacte.
La limite de gestion des fichiers des systèmes d'exploitation pour l'utilisateur mysql peut également être un problème (sous linux, la valeur par défaut peut souvent être 1024, ulimit -n pour afficher les limites de l'utilisateur), cela peut entraîner un problème avec un grand nombre de tables lorsqu'il est inférieur au nombre mysql nécessite. Cela devrait être au moins le même que la limite des fichiers ouverts.
Comme pour toute base de données, il existe des centaines de paramètres de réglage que vous pouvez ajuster pour optimiser la base de données pour votre schéma particulier. MySQL est pire pour cela que la plupart car vous pouvez brancher des moteurs supplémentaires si vous le souhaitez, c'est-à-dire le moteur de cluster NDB.
http://dev.mysql.com/doc/refman/5.1/en/table-cache.html
J'espère que cela aide
Pour chaque index de table, MySQL a son propre index. L'index prend de la mémoire pour la conserver et l'utiliser, et il y a une limite globale pour les index. Lorsqu'il y a plusieurs tables, les index ne peuvent pas tous être en RAM, ils vont donc sur le disque, ce qui affecte directement les performances. Essayez d'augmenter ceci my.cnf:: key_buffer_size=256Mc'est la quantité de RAM mise de côté pour contenir les informations d'index.
Peut-il? Sûr. Mais combien dépend beaucoup de votre application et de ses modèles d'accès, et si vous utilisez myisam ou innodb, et si innodb est en mode fichier par table ou non, et la taille des journaux innodb. Vous devrez nous donner plus de détails que cela.
Non - je ne pense pas que le nombre de tables sera le goulot d'étranglement des performances de votre système. Après tout, ce ne sont que des fichiers sur votre système de fichiers. Il n'y a rien d'inhabituel à avoir des centaines de tables dans une base de données.
Il est beaucoup plus probable que vos requêtes ne soient pas correctement optimisées. Je conseillerais d'activer le log-slow-querieset log-queries-not-using-indexes. Lorsque vous identifiez des requêtes lentes, utilisez l' explainoption pour afficher le plan de requête pour ces requêtes afin d'identifier les emplacements où les index sont manquants.
Voir http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html pour plus de détails.