La Table de hachage de la Structure de Données dans SQL Server

C'est trop long pour un commentaire.

De hachage basée sur les algorithmes sont importants pour qu'une base de données puissante. Ceux-ci sont utilisés pour l'agrégation et des opérations de jointure. De hachage basée sur les jointures ont été là depuis la version 7.0, qui est vraiment vieux (merci à Martin Smith). Vous pouvez lire plus sur eux dans les la documentation.

SQL Server 2014 introduit de hachage basée sur les indices de la mémoire optimisée des tables (voir ici). Ce sont explicitement l'utilisation de tables de hachage. En général, cependant, les arbres, les indices sont plus puissants, car ils peuvent être utilisés dans des situations plus:

• De plage de recherches (y compris like).
• Pour une partie de la clé correspond.
• Pour order by.

Un index de hachage ne peut être utilisé pour une exacte égalité match (et group by).

Veuillez considérer également les notes suivantes comme un long commentaire et non comme réponse distincte:

[ 1 ] SQL Server ont join (INNER HASH JOIN) et les indicateurs de requête (OPTION (HASH JOIN), OPTION(HAS GROUP')) afin d'appliquer un tel physique des jointures ou de regroupement.

[ 2 ] en Interne, SQL Server utilise une table de hachage, de verrouiller les identificateurs. Voir les sans-papiers, la fonction %%lockres%% (réf. http://www.sqlskills.com/blogs/paul/investigating-locking-and-deadlocking-with-lockres/).

USE tempdb
GO
CREATE TABLE dbo.Documents (
ID          INT IDENTITY(1,1) PRIMARY KEY,
DocDate     DATE NOT NULL,
Content     VARCHAR(8000) NOT NULL
);
CREATE INDEX IX_Documents_DocDate
ON dbo.Documents (DocDate)
GO
INSERT  dbo.Documents (DocDate, Content)
VALUES  
('2016-01-01', REPLICATE(CONVERT(VARCHAR(MAX), 'A'), 4000)),
('2016-02-02', REPLICATE(CONVERT(VARCHAR(MAX), 'B'), 5000)),
('2016-03-04', REPLICATE(CONVERT(VARCHAR(MAX), 'C'), 6000));
GO
SELECT  ID, DocDate, %%lockres%% AS record_lock_hash
FROM    dbo.Documents WITH(INDEX=1) -- Clustered index
GO
/*
ID          DocDate    record_lock_hash
----------- ---------- --------------------------------
1           2016-01-01 (8194443284a0)
2           2016-02-02 (61a06abd401c)
3           2016-03-04 (98ec012aa510)
*/
GO
SELECT  ID, DocDate, %%lockres%% AS record_lock_hash
FROM    dbo.Documents WITH(INDEX=IX_Documents_DocDate) -- Non-Clustered index
GO
/*
ID          DocDate    record_lock_hash
----------- ---------- --------------------------------
1           2016-01-01 (417e1de8c3fb)
2           2016-02-02 (6aede25aab61)
3           2016-03-04 (e701c6578164)
*/
GO

[ 3 ] en tant Que développeur de base de données, j'ai utilisé des "tables de hachage" (une colonne calculée définie en utilisant une fonction de hachage) pour l'indice de la taille du texte (ou gouttes) donc:

ALTER TABLE dbo.Documents 
ADD ContentHash AS CHECKSUM(HASHBYTES('sha256', Content)) /*PERSISTED*/ -- Computed column
GO
SET ANSI_NULLS, QUOTED_IDENTIFIER ON
GO
SET ANSI_WARNINGS, ANSI_PADDING, ARITHABORT, CONCAT_NULL_YIELDS_NULL ON
SET NUMERIC_ROUNDABORT OFF
GO
CREATE INDEX IX_Documents_ContentHash
ON dbo.Documents (ContentHash) 
--INCLUDE (Content)
GO
DECLARE @ParamContent VARCHAR(8000) = REPLICATE(CONVERT(VARCHAR(MAX), 'B'), 5000)
DECLARE @ParamHash INT = CHECKSUM(HASHBYTES('sha256', @ParamContent))
SELECT  d.ID, d.Content
FROM    dbo.Documents d WITH(FORCESEEK)
WHERE   d.ContentHash = @ParamHash  -- Index Seek Predicate (Fast/optimized if there is an index on ContentHash computed column)
AND     d.Content = @ParamContent   -- [Simple /non-indexed] Predicate (Slow)
GO

Remarque: veuillez jouer avec attention quand l'indexation des colonnes calculées (voir les conditions pour SETtings).