Per rispondere alla tua domanda:sì, diventerà meno performante. Ovviamente, più grande è il tipo, più grande è la tabella, più lente sono le query (più I/O, indici più grandi, tempo di accesso più lungo, meno probabilità di adattarsi alle varie cache e così via). Quindi, come regola pratica:usa sempre il tipo più piccolo quello che ti serve.
Detto questo, le prestazioni non contano . Come mai? Perché quando raggiungi un punto in cui trabocchi un INT, BIGINT è l'unica soluzione e dovrai conviverci. Inoltre a quel punto (considerando che stai utilizzando un PK con incremento automatico, sarai oltre 4 miliardi righe), avrai problemi di prestazioni maggiori e l'overhead di un BIGINT rispetto a un INT sarà l'ultima delle tue preoccupazioni.
Quindi, considera i seguenti punti:
- Utilizza UNSIGNED se non hai bisogno di valori negativi, questo raddoppierà il limite.
- Il valore massimo di UNSIGNED INT è 4.294.967.295. Se stai utilizzando un PK a incremento automatico e hai solo 300.000 voci, non devi davvero preoccuparti . Al momento potresti anche usare un MEDIUMINT, a meno che tu non stia pianificando una crescita davvero molto veloce. (vedi http://dev.mysql.com/doc /refman/5.1/en/integer-types.html )
- Il numero tra parentesi dopo il tipo non influisce sul valore massimo del tipo . INT(7) è uguale a INT(8) o INT(32). Viene utilizzato per indicare la larghezza di visualizzazione se specifichi ZEROFILL (vedi http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html )
