• L'indice des primary keys commence à 1 et non à 0 (donc faire bien attention avec des insert efrectués manuellement lorsque l'on veut s'assurer qu'un tuple dispose d'un ID en particulier).

• Mieux vaut utiliser des ID en UNSIGNED, par exemle :

  id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT

Ceux-ci permettent de n'avoir que des ID positifs et rangés pas ordre croissant, ce qui améliore la recherche. De plus votre limite passera de 2 millards d'entrées à 4 milliards d'entrées dans cette table.

• Préférez le type INT UNSIGNED à BIGINT (qui peut aussi être UNSIGNED). Vous ferai une économie mémoire d'environ 12% sur les recherches et économiserez 4 octets sur le disque par tuple ayant un id (et ceci pour chaque table).

Limitations :

• BIGINT UNSIGNED permet de gérer jusqu'à 2^64 - 1 entrées alors que INT UNSIGNED jusqu'à 2^32 - 1. On risque d'atteindre plus rapidement la limite non ?

==> Oui c'est vrai, mais admettons que :

• Notre système encaisse 100 000 insertions / jour.
• Cela fera 36 500 000 d'insertions / an.
• Soit 3 650 000 000 insertions pour 1 siècle.

Si votre application est toujours là dans 10 an ce sera déjà énorme alors 1 SIÈCLE !!!

Moralité, nous ne sommes pas Google.