Les connexions persistantes ne devraient pas être nécessaires pour MySQL. Dans d'autres bases de données (telles qu'Oracle), établir une connexion est coûteux et prend du temps, donc si vous pouvez réutiliser une connexion, c'est une grande victoire. Mais ces marques de base de données proposent un regroupement de connexions, ce qui résout mieux le problème.
La connexion à une base de données MySQL est rapide par rapport à ces autres marques, donc l'utilisation de connexions persistantes offre proportionnellement moins d'avantages pour MySQL que pour une autre marque de base de données.
Les connexions persistantes ont aussi un inconvénient. Le serveur de base de données alloue des ressources à chaque connexion, que les connexions soient nécessaires ou non. Vous voyez donc beaucoup de ressources gaspillées inutilement si les connexions sont inactives. Je ne sais pas si vous atteindrez 10 000 connexions inactives, mais même quelques centaines coûtent cher.
Les connexions ont un état, et il serait inapproprié qu'une requête PHP "hérite" des informations d'une session précédemment utilisée par une autre requête PHP. Par exemple, les tables temporaires et les variables utilisateur sont normalement nettoyées lorsqu'une connexion se ferme, mais pas si vous utilisez des connexions persistantes. De même, les paramètres basés sur la session tels que le jeu de caractères et le classement. Aussi, LAST_INSERT_ID() rapporterait le dernier identifiant généré pendant la session - même si c'était lors d'une requête PHP précédente.
Pour MySQL au moins, les inconvénients des connexions persistantes l'emportent probablement sur leurs avantages. Et il existe d'autres techniques plus efficaces pour atteindre une évolutivité élevée.
Mise à jour mars 2014 :
La vitesse de connexion à MySQL a toujours été faible par rapport aux autres marques de SGBDR, mais elle s'améliore encore.
Voir http://mysqlserverteam.com/improving-connectdisconnect-performance/
Lisez le blog pour plus de détails et des comparaisons de vitesse.
