4520 shaares
1 résultat
taggé
insertions
-
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.