Je sais que c'est une bonne idée dans MySQL. Si je vous rappelle correctement, dans MySQL, il permet aux index de travailler plus efficacement.
3 Réponses :
Non, tant que vous ne stockez pas réellement les NULLS dans la table, les index seront exactement les mêmes (et tout aussi efficaces).
Réglage de la colonne pour NON NULLL a beaucoup d'autres avantages, donc vous devriez toujours le mettre à ce sujet lorsque vous ne prévoyez pas stocker NULLS. -)
C'est toujours un bon idéal pour garder des colonnes d'être nulle si vous pouvez l'éviter, car la sémantique de l'utilisation est si désordonnée; Voir Quel est l'accord avec NULLS? pour une bonne discussion sur la manière dont ils peuvent vous mettre en difficulté.
Dans les versions de PostgreSQL jusqu'à 8.2, le logiciel ne savait pas comment faire des comparaisons sur l'index de type le plus courant (The B-Tree) d'une manière qui inclurait la recherche de valeurs nulles. Dans le bit pertinent de Documentation sur les types d'index , vous pouvez Voir que décrit comme "mais note que NULL n'est pas équivalent à = et n'est pas indexable". L'évolution effective à cet égard est que si vous spécifiez une requête qui nécessite inclure des valeurs NULL, le planificateur pourrait ne pas être en mesure de le satisfaire à l'aide de l'indice évident pour cette affaire. En règle générale, si vous avez une commande par déclaration pouvant être accélérée avec un index, mais votre requête doit également renvoyer les valeurs null, l'optimiseur ne peut pas utiliser cet index car le résultat manquera de toutes les données NULL - et donc être incomplet et inutile. L'optimiseur le sait et fera plutôt une analyse non annoncée de la table, ce qui peut être très coûteux.
postgreSQL L'amélioration de cela dans 8.3 , "A est Null condition sur une colonne d'index peut être utilisée avec un index B-Tree ". Donc, les situations où vous pouvez être brûlé en essayant d'indexer quelque chose avec des valeurs nuls ont été réduites. Mais comme la sémantique nulelle est toujours vraiment douloureuse et que vous pourriez rencontrer une situation où le planificateur de 8.3 ne fait pas ce que vous attendez à cause d'eux, vous devriez toujours utiliser non NULL chaque fois que possible pour réduire vos chances de courir dans une requête mal optimisée .
Super commentaire ... Je ne savais pas cette relation entre non nulle et index. Merci Mec!
réglage Mais vous pouvez améliorer les performances en utilisant réellement des nuls au lieu de valeurs factices. Selon les types de données, vous pouvez Le bitmap NULL n'est attribué que s'il y a des valeurs nulles dans la rangée . C'est un bit pour chaque colonne de la ligne (null ou non). Pour les tables jusqu'à 8 colonnes, le null bitmap est effectivement totalement libre, en utilisant un octet de rechange entre l'en-tête de tuple et les données de ligne. Après cela, l'espace est attribué dans des multiples de L'exigence de stockage minimale pour toute valeur non nulle est 1 octeen ( plus sur NULL STOCKAGE:
non null n'a aucun effet en soi sur la performance. Quelques cycles pour le chèque - non pertinents.
maxalign (typiquement 8 octets, couvrant 64 colonnes). La différence est perdue au rembourrage. Donc, vous payez le prix complet (bas!) Pour booléen , "char" , ...) ou typiquement beaucoup plus, plus (éventuellement) rembourrage pour l'alignement. Lisez sur Types de données ou vérifier les détails de Gory dans la table système < Code> pg_type .
Qu'entendez-vous par «quelques cycles pour le chèque»?
@Mattdipasquale: Postgrees doit faire respecter la contrainte et soulever une exception si elle n'est pas remplie. Étant donné que les tests pour NULL sont si simples, le coût est négligeable.