Pour répondre à votre question :oui, il deviendra moins performant. Évidemment, plus le type est grand, plus la table est grande, plus les requêtes sont lentes (plus d'E/S, index plus gros, temps d'accès plus long, résultat moins susceptible de tenir dans les différents caches, etc.). Donc, en règle générale :utilisez toujours le type le plus petit qui correspond à vos besoins.
Cela étant dit, les performances n'ont pas d'importance . Pourquoi? Parce que lorsque vous atteignez un point où vous débordez d'un INT, alors BIGINT est la seule solution et vous devrez vivre avec. Également à ce stade (en considérant que vous utilisez un PK à incrémentation automatique, vous serez supérieur à 4 milliards rows), vous aurez des problèmes de performances plus importants, et la surcharge d'un BIGINT par rapport à un INT sera le cadet de vos soucis.
Alors, considérez les points suivants :
- Utilisez UNSIGNED si vous n'avez pas besoin de valeurs négatives, cela doublera la limite.
- La valeur maximale UNSIGNED INT est 4.294.967.295. Si vous utilisez un PK à incrémentation automatique et vous n'avez que 300 000 entrées, vous n'avez vraiment pas à vous inquiéter . Vous pouvez même utiliser un MEDIUMINT pour le moment, à moins que vous ne prévoyiez une croissance vraiment très rapide. (voir http://dev.mysql.com/doc /refman/5.1/fr/types-entiers.html )
- Le nombre entre parenthèses après le type n'a pas d'incidence sur la valeur maximale du type . INT(7) est identique à INT(8) ou INT(32). Il est utilisé pour indiquer la largeur d'affichage si vous spécifiez ZEROFILL (voir http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html )
