Bien que je ne connaisse pas les mécanismes internes spécifiques qui sont responsables des différences, je peux dire que les tas sont gérés (en interne) légèrement différemment des index clusterisés (et peut-être aussi des index non clusterisés):
La suppression de lignes d'un segment de mémoire de sorte qu'une ou plusieurs pages de données sont vides (aucune ligne allouée) ne libère pas nécessairement cet espace. Vous devrez probablement créer, puis supprimer, un index cluster sur la table, ou appeler ALTER TABLE [TableName] REBUILD;(à partir de SQL Server 2014?). Veuillez consulter la page Microsoft Docs pour SUPPRIMER pour plus de détails et d'options.
L'insertion de lignes individuelles (c'est-à-dire non basées sur un ensemble INSERT) dans un segment de mémoire ne remplit pas les pages de données aussi complètement qu'avec les index clusterisés. Les index clusterisés s'adapteront aux lignes tant qu'il y aura de l'espace pour la ligne (données et surcharge de ligne) plus la surcharge de 2 octets de la baie de logements. Les pages de données dans Heaps, cependant, n'utilisent pas le nombre d'octets restant sur la page, mais utilisent plutôt un indicateur très généralisé de la façon dont la page est pleine, et il n'y a pas autant de niveaux qui sont signalés. Les niveaux sont quelque chose comme: 0%, 20%, 50%, 80% et 100% plein. Et il passera à 100% alors qu'il y a encore de l'espace pour une autre ligne (et en fait, si ce même nombre de lignes avait été inséré dans une opération basée sur un ensemble, il aurait rempli la page autant que possible). Bien sûr, tout comme avec leDELETE , la reconstruction du segment de mémoire contiendra autant de lignes qu'il y en aura sur la page de données.
Considérez maintenant les informations suivantes, extraites de la section «Quand la compression de page se produit» de la page Microsoft Docs pour l' implémentation de la compression de page :
... Lorsque des données sont ajoutées à la première page de données, les données sont compressées en ligne. ... Lorsque la page est pleine, la ligne suivante à ajouter lance l'opération de compression de page. La page entière est revue; ...
Par conséquent, il semble tout à fait conforme à cet autre comportement de tas qu'ils nécessiteraient une ALTER TABLE REBUILD, CREATE / DROP d'un index clusterisé ou une modification du paramètre de compression de données (qui reconstruisent tous le tas) avant l'écriture des pages de données de manière optimale. Si les tas ne sont pas pleinement conscients des "pages entières" (jusqu'à ce que le tas soit reconstruit) et ne savent pas quand la page est définitivement pleine, alors ils ne sauraient pas quand lancer l'opération de compression de page (lorsqu'il s'agit de mises à jour et d'un seul -inserts de flèche).
Une autre technicité qui limiterait davantage certains segments de l'application automatique de la compression de page (même s'ils le pourraient autrement) est que l'application de la compression nécessiterait que tous les index non clusterisés pour ce segment de mémoire (le cas échéant) soient reconstruits. Comme l'indique cette page liée pour "Data Compression":
La modification du paramètre de compression d'un segment nécessite que tous les index non cluster de la table soient reconstruits de sorte qu'ils aient des pointeurs vers les nouveaux emplacements de ligne dans le segment.
Les "pointeurs" auxquels il est fait référence sont les ID de ligne (RID), qui sont une combinaison de: FileID, PageID et slot / position sur la page. Ces RID sont copiés dans des index non clusterisés. Étant un emplacement physique précis, il s'agit parfois de recherches plus rapides que de parcourir un arbre b avec les clés d'index cluster. Mais, un inconvénient d'un emplacement physique est qu'il peut changer, et c'est le problème ici. Toutefois, les index cluster ne souffrent pas de ce problème car leurs valeurs de clé sont copiées dans des index non cluster comme pointeur vers l'index cluster. Et les valeurs clés restent les mêmes, même lorsque leur emplacement physique change.
Regarde aussi:
la section "Gestion des segments" de la page Microsoft Docs pour les segments (tables sans index cluster) :
Pour reconstruire un segment de mémoire pour récupérer de l'espace perdu, créez un index cluster sur le segment, puis supprimez cet index cluster.
la section «Considérations pour l'utilisation de la compression de lignes et de pages» de la page Microsoft Docs pour la compression de données :
Lorsqu'un segment est configuré pour la compression au niveau de la page, les pages ne reçoivent la compression au niveau de la page que des manières suivantes:
- Les données sont importées en masse avec des optimisations en masse activées.
- Les données sont insérées à l'aide de la syntaxe INSERT INTO ... WITH (TABLOCK) et la table n'a pas d'index non cluster.
- Une table est reconstruite en exécutant l'instruction ALTER TABLE ... REBUILD avec l'option de compression PAGE.
Et la déclaration citée dans la question.