Il s'agit d'une question dérivée de l' ordre de tri spécifié dans la clé primaire, mais le tri est exécuté sur SELECT .
@Catcall le dit au sujet de l'ordre de stockage (index clusterisé) et de l'ordre de sortie
Beaucoup de gens pensent qu'un index clusterisé garantit un ordre de tri sur la sortie. Mais ce n'est pas ce qu'il fait; il garantit un ordre de stockage sur disque. Voir, par exemple, cet article de blog .
J'ai lu l'article de blog de Hugo Kornelis et je comprends qu'un index ne garantit pas que le serveur SQL lit les enregistrements dans un ordre spécifique. Pourtant, j'ai du mal à accepter que je ne peux pas assumer cela pour mon scénario?
CREATE TABLE [dbo].[SensorValues](
[DeviceId] [int] NOT NULL,
[SensorId] [int] NOT NULL,
[SensorValue] [int] NOT NULL,
[Date] [int] NOT NULL,
CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED
(
[DeviceId] ASC,
[SensorId] ASC,
[Date] DESC
) WITH (
FILLFACTOR=75,
DATA_COMPRESSION = PAGE,
PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF,
ONLINE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [MyPartitioningScheme]([Date])
Ma requête d'origine était la suivante:
SELECT TOP 1 SensorValue
FROM SensorValues
WHERE SensorId = 53
AND DeviceId = 3819
AND Date < 1339225010
ORDER BY Date DESC
Mais je suggère que je pourrais aussi bien utiliser celui-ci (lire ci-dessous pour mon explication):
SELECT TOP 1 SensorValue
FROM SensorValues
WHERE SensorId = 53
AND DeviceId = 3819
AND Date < 1339225010
Comme vous pouvez le voir, mes lignes de table sont petites (16 octets) et je n'ai qu'un seul index, un cluster. Dans mon scénario, la table se compose de 100 000 000 d'enregistrements en ce moment (et cela augmentera très probablement dix fois).
Lorsque le serveur de base de données interroge cette table, il a deux façons de trouver mes lignes, soit il recherche la clé primaire et donc lit et renvoie mes valeurs en desc. ordre de date, ou il doit faire une analyse complète de la table. Ma conclusion est qu'une analyse complète de la table sur tous ces enregistrements sera beaucoup trop lente et le serveur de base de données cherchera donc toujours la table via sa clé primaire et retournera ainsi les valeurs triées parDate DESC
ORDER BY
clause est un gros coup de performance pour moi (lire l' autre question pour plus d'infos). J'ai une solution qui fonctionne pour l'instant, mais elle ne tiendra pas quand et si mon trafic augmente.
ORDER BY
clause dans votre requête. Cela est vrai pour SQL Server , Oracle , MySQL et tout autre SGBDR auquel vous pouvez penser. Essayez autre chose et vous vous préparez pour une tasse surprise de FAIL.
ORDER BY
dessus, alors vous savez que vous pouvez vous y fier. Voir # 3 ici