Définir MySQL sans explicite clés primaires est une très très mauvaise idée.
Si une PK est manquante, MySQL créera une clé primaire implicite (mais très réelle) à incrémentation automatique.
Cette PK sera incluse dans chaque clé secondaire dans InnoDB et déterminera votre ordre de tri principal dans MyISAM.
Conséquence
Vous venez de ralentir les performances de chaque sélection, insertion et mise à jour.
Pour rien au monde.
InnoDB :recherche supplémentaire requise pour accéder aux données de la table
Dans InnoDB, une recherche supplémentaire doit être effectuée, car tous les index secondaires se réfèrent au PK et non aux lignes elles-mêmes.
MyISAM :espace perdu
Dans MyISAM, la pénalité n'est pas si importante, mais vous faites toujours glisser un champ inutilisé de 4 octets qui n'est pas utilisé.
InnoDB + MyISAM :Génération inutile de champ d'auto-incrémentation
Parce qu'un PK d'auto-incrémentation implicite est créé et que vous avez également besoin d'une clé d'auto-incrémentation supplémentaire pour effectuer des jointures ; Afin d'éviter les champs d'auto-incrémentation en double, vous n'avez plus 1, mais 2 verrous de table par insertion.
InnoDB :avec les jointures, le problème de recherche mentionné ci-dessus double
Si vous effectuez une jointure en utilisant un champ qui n'est pas le PK, InnoDB doit effectuer une recherche supplémentaire par jointure pour accéder aux enregistrements de cette autre table.
InnoDB :le pire de tout, vous perdez l'avantage de couvrir les index
Vous avez désactivé l'une des meilleures optimisations d'InnoDB, couvrant les index.
Si MySQL peut résoudre la requête en utilisant uniquement les données des index, il ne lira jamais la table, cela se traduira par une vitesse significative Gain. Maintenant que 50 % de chaque index dans InnoDB est un espace inutilisé, vous venez d'annuler vos chances d'utiliser cette optimisation.
Veuillez battre cet entrepreneur avec un bâton indice !
Liens :
http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/
(lien lent, mais lecture recommandée).
O'Reilly sur les index de couverture d'InnoDB
http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB
BTW , si votre entrepreneur dit que cela n'a pas beaucoup d'importance parce qu'il utilise MyISAM, battez-le encore, vous devriez toujours utiliser InnoDB à moins que vous n'ayez une bonne raison de ne pas le faire.
InnoDB est beaucoup plus sûr en production, MyISAM a ses utilise mais se corrompt trop facilement.
