155
6.1 Principes de l’indexation
Ici nous constatons plusieurs choses : le résultat pour la table et pour l’index clustered est le même. La page d’index et la page de table ont le même ID, c’est donc la
même. Nous voyons aussi que la page de données se trouve au niveau 0 (le nœud
feuille) de l’index clustered (1). Cela signifie donc que la page de données, et la page
du niveau feuille de l’index clustered, est la même.
En effet, lorsque vous créez un index clustered, la table devient partie de l’index :
le nœud feuille de l’index clustered est… la table elle-même ! Il est important de
comprendre ce fait. Une table de type heap, et une table clustered, sont deux objets
bien différents. Lorsque SQL Server effectue un seek dans un index clustered, il ne
quitte jamais l’index, et la notion de RID n’existe plus. Quand la recherche arrive au
dernier niveau de l’index, elle est terminée, car on se trouve déjà au bon endroit :
dans la page de données. Ainsi, contrairement à un index nonclustered, ce qui se
trouve dans le nœud feuille n’est pas uniquement la clé de l’index, mais aussi toutes
les autres colonnes de la table.
Cela implique également que la table clustered comporte un ordre de pages.
Comme la table est le dernier niveau de l’index, elle maintient comme les index une
liste doublement liée de ses pages. Cela permet un scan de la table, pour retrouver
des lignes dans l’ordre de la clé de l’index clustered. Une table heap, par contre, n’a
aucune notion de page précédente ou page suivante, puisque ses lignes ne sont organisées dans aucun ordre explicite. Pour un heap, SQL Server sait qu’une page fait
partie de la table, en inspectant les pages IAM de la table.
Bien qu’elle n’ait aucune particularité d’un index, la table heap est elle aussi, en
interne, considérée comme un index : elle apparaît dans la vue sys.indexes, comme un index de type heap, et ses pages sont allouées également par des pages
d’IAM (Index Allocation Map).
Qu’en est-il des index nonclustered sur une table clustered ? Ils sont aussi d’une
autre espèce. Observons leur différence fondamentale. Pour cela, nous allons ajouter
un certain nombre de lignes dans notre table de démo, et une troisième colonne que
nous allons indexer :
DECLARE @i int
SELECT @i = MAX(id)+1 FROM dbo.indexdemo;
WHILE @i <= 2000 BEGIN
INSERT INTO dbo.indexdemo (id) SELECT @i;
SET @i = @i + 1
END
ALTER TABLE dbo.indexdemo
ADD petittexte CHAR(1) NULL;
GO
UPDATE dbo.indexdemo
SET petittexte = CHAR(ASCII('a')+(id%26))
6.1 Principes de l’indexation
Ici nous constatons plusieurs choses : le résultat pour la table et pour l’index clustered est le même. La page d’index et la page de table ont le même ID, c’est donc la
même. Nous voyons aussi que la page de données se trouve au niveau 0 (le nœud
feuille) de l’index clustered (1). Cela signifie donc que la page de données, et la page
du niveau feuille de l’index clustered, est la même.
En effet, lorsque vous créez un index clustered, la table devient partie de l’index :
le nœud feuille de l’index clustered est… la table elle-même ! Il est important de
comprendre ce fait. Une table de type heap, et une table clustered, sont deux objets
bien différents. Lorsque SQL Server effectue un seek dans un index clustered, il ne
quitte jamais l’index, et la notion de RID n’existe plus. Quand la recherche arrive au
dernier niveau de l’index, elle est terminée, car on se trouve déjà au bon endroit :
dans la page de données. Ainsi, contrairement à un index nonclustered, ce qui se
trouve dans le nœud feuille n’est pas uniquement la clé de l’index, mais aussi toutes
les autres colonnes de la table.
Cela implique également que la table clustered comporte un ordre de pages.
Comme la table est le dernier niveau de l’index, elle maintient comme les index une
liste doublement liée de ses pages. Cela permet un scan de la table, pour retrouver
des lignes dans l’ordre de la clé de l’index clustered. Une table heap, par contre, n’a
aucune notion de page précédente ou page suivante, puisque ses lignes ne sont organisées dans aucun ordre explicite. Pour un heap, SQL Server sait qu’une page fait
partie de la table, en inspectant les pages IAM de la table.
Bien qu’elle n’ait aucune particularité d’un index, la table heap est elle aussi, en
interne, considérée comme un index : elle apparaît dans la vue sys.indexes, comme un index de type heap, et ses pages sont allouées également par des pages
d’IAM (Index Allocation Map).
Qu’en est-il des index nonclustered sur une table clustered ? Ils sont aussi d’une
autre espèce. Observons leur différence fondamentale. Pour cela, nous allons ajouter
un certain nombre de lignes dans notre table de démo, et une troisième colonne que
nous allons indexer :
DECLARE @i int
SELECT @i = MAX(id)+1 FROM dbo.indexdemo;
WHILE @i <= 2000 BEGIN
INSERT INTO dbo.indexdemo (id) SELECT @i;
SET @i = @i + 1
END
ALTER TABLE dbo.indexdemo
ADD petittexte CHAR(1) NULL;
GO
UPDATE dbo.indexdemo
SET petittexte = CHAR(ASCII('a')+(id%26))