Moteur optimal pour les petites tables de recherche dans MySQL

Question

J'ai la question suivante :Je conçois une application web avec plusieurs dizaines de petites tables de recherche :Ces tableaux contiennent généralement trois colonnes (ID, Nom, Description) et quelques lignes (généralement moins de 50, le maximum est d'environ 450).

Ces tables de recherche ne devraient changer que rarement (elles proviennent du standard, qui change une fois tous les plusieurs années) et ne seront utilisées que pour :

• remplir les options en html sélectionner
• être joint à d'autres enregistrements dans les rapports

Il n'y aura que SELECT déclarations sur ces tableaux 99 % des fois, mais il y en aura beaucoup.

Je me demande quel moteur de base de données serait le plus efficace à utiliser ?

Voici mes considérations :

MÉMOIRE

• pro:très vite
• escroquer:si le serveur tombe en panne, toutes les données sont perdues et doivent être recréées
• escroquer:ne prend pas en charge les clés étrangères

MyISAM compressé

• pro:rapide
• escroquer:ne prend pas en charge les clés étrangères

InnoDB

• pro:prise en charge des clés étrangères

Ce que je voudrais demander, c'est s'il y aura un avantage significatif à utiliser quelque chose de différent de InnoDB - en termes de performances

Merci, Zbynek

Answer 1

J'ai répondu à une question similaire en août 2011: Quel SGBM est bon pour des lectures super-rapides et une structure de données simple?

Puisque vous vous demandez à propos de MySQL et quel moteur de stockage. Pour être honnête, il est difficile de dire car il y a de rares occasions lorsque MyISAM peut surperformer InnoDB lorsqu'il s'agit de sélectionner.

Voici quelques-uns de mes postes antérieurs sur cette controverse

• Sep 20, 2011: meilleur de Myisam et Innodb
• May 03, 2012: qui est plus rapide, innodb ou myisam? < / a>
• Jul 05, 2012: innodb vs myisam avec de nombreux index
• Sep 26, 2012: Choisir Myisam sur InnoDB pour ces exigences de projet; et des options à long terme

Vous pourriez demander maintenant: pourquoi je feraisrai-je déjà favoriser Myisam sur InnoDB?

Regardez ce diagramme (créé par Vadim Tkachenko, Percona CTO)

Myisam cache des index et votre table aurait 2 index (clé primaire sur ID et index de nom). D'autre part, InnoDB a trop de pièces mobiles pour accueillir, surtout si le pool de tampons InnoDb doit charger et rejeter périodiquement les pages de 16 km.

Pour être juste, vous devriez faire une expérience.

• aller à ma post sont les principales différences entre Innodb et Myisam? . Lisez-le soigneusement.
• Configurez un serveur à l'aide de MyISAM et toutes vos tables à l'aide de ROW_FORMAT=Fixed (voir mon message Quel est l'impact de la performance de l'utilisation de Char VS Varchar sur un champ de taille fixe? ) et utilisez un grand Key_Buffer_Size .
• Configurez un autre serveur à l'aide d'innoDB et d'un grand innodb_buffer_pool_size .
• Ajoutez vos données au serveur et les interroge comme un fou.

Cela vous donnera la meilleure évaluation du choix du moteur de stockage pour votre jeu de données.

Essayez !!!

Answer 2

• "MyISAM compressé" -- qu'est-ce que c'est ?Peut-être « Archiver » ?
• La compression n'est pas nécessaire ;les tables sont trop petites et seront rapidement entièrement mises en cache.
• FOREIGN KEYS -- Pourquoi?Vous avez débogué votre code, n'est-ce pas ?Il n’y aura aucune chose en suspens à vérifier.
• MEMORY n'est pas déraisonnable, si vous écrivez du code « recharger » qui s'exécute chaque fois que vous ouvrez le serveur, et toutes les mises à jour de la table sont écrites à la fois dans le MEMORY table et la sauvegarde persistante.
• MyISAM ROW_FORMAT=FIXED -- c'est un conte de vieille femme ;utiliser DYNAMIC et VARCHARs.
• Le "cluster" d'InnoDB PRIMARY KEY rend les recherches un peu plus rapides que MyISAM pour votre objectif.
• Est-ce que tu savoir que les tables de recherche provoquent un ralentissement notable ?J'en doute sérieusement.
• Faire pas utilisez des tables de recherche pour les valeurs « continues », telles que FLOATs et DATEs.

Je vote pour InnoDB sans FK.