Discussion :

[Kropernic]

Bonjour,

En considérant la table dont voici le DDL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
USE [GIFT_MANAGEMENT]
GO
 
/****** Object:  Table [dbo].[T_SERIAL_SER]    Script Date: 11/08/2012 09:52:29 ******/
SET ANSI_NULLS ON
GO
 
SET QUOTED_IDENTIFIER ON
GO
 
CREATE TABLE [dbo].[T_SERIAL_SER](
    [SER_ID] [int] IDENTITY(1,1) NOT NULL,
 CONSTRAINT [PK_T_SERIAL_SER] PRIMARY KEY CLUSTERED 
(
    [SER_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO

Est-il correct de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
SELECT TOP 1
        SER_ID AS 'CRD_SERIAL'
FROM
        DBO.T_SERIAL_SER SER
WHERE
        SER_ID > @UNE_VALEUR 
    AND SER_ID NOT IN    (
                        @X,@Y,@Z
                        )

Plutôt que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
SELECT 
        MIN(SER_ID) AS 'CRD_SERIAL'
FROM
        DBO.T_SERIAL_SER SER
WHERE
        SER_ID > @UNE_VALEUR 
    AND SER_ID NOT IN    (
                        @X,@Y,@Z
                        )

Alors je sais qu'il n'y a pas d'ordre dans une table. Que c'est un sac de billes. Mais le fait d'introduire un index cluster n'apporte-t-il pas de l'ordre ?

Je pose cette question car cette petite requête toute simple s'intègre dans en fait dans une plus grande et est le membre de droite d'une clause OUTER APPLY. Le truc est qu'avec le 2e bout de code, je ne vois jamais le bout de la requête... Alors qu'avec le 1e, c'est immédiat ou presque.


Pour info, voici la requête complete :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
    SELECT
            CRD.TCA_ID,
            CRD.CRD_RECHARGEABLE,
            MIN(CRD.CRD_SERIAL) AS 'MIN',
            MAX(CRD.CRD_SERIAL) AS 'MAX'
    FROM
            DBO.T_GIFT_COMMANDE_GFC GFC
                INNER JOIN dbo.T_CARD_CRD CRD
                    ON    GFC.GFT_ID = CRD.GFT_ID 
                OUTER APPLY    (
                            SELECT TOP 1
                                    SER_ID AS 'CRD_SERIAL'
                            FROM
                                    DBO.T_SERIAL_SER SER
                            WHERE
                                    SER_ID > CRD.CRD_SERIAL 
                                AND SER_ID NOT IN    (
                                                    SELECT
                                                            CRD_SERIAL
                                                    FROM
                                                            DBO.T_GIFT_COMMANDE_GFC GFC2
                                                                INNER JOIN dbo.T_CARD_CRD CRD3
                                                                    ON    GFC2.GFT_ID = CRD3.GFT_ID 
                                                    WHERE
                                                            CRD3.TCA_ID = CRD.TCA_ID 
                                                        AND GFC2.CMD_ID = @CMD_ID
                                                    )
                            ) T
    WHERE
            GFC.CMD_ID = @CMD_ID 
    GROUP BY
            CRD.TCA_ID,
            CRD.CRD_RECHARGEABLE,
            T.CRD_SERIAL
    ORDER BY
            CRD.TCA_ID,
            CRD.CRD_RECHARGEABLE,
            [MIN]

[StringBuilder]

Non, ce n'est pas correct.

Rien n'empêche ton SGBD de lire l'index à l'envers s'il a envie.
Ou d'utiliser un autre index que celui de la PK.

Le TOP 1 ID est équivalent au MIN(ID) si et seulement si le TOP 1 ID est associé à un ORDER BY ID ASC

[Kropernic]

J'ai bien précisé que je posais la question dans le cadre de la table dont j'ai posté le DDL.

Donc pas d'autre index possible que celui cluster.

Ca arrive vraiment que le SGBDR lise un index à l'envers ? 0_0

Quant à la clause order by, n'est pas justement implicite à cause de l'index justement ?

[StringBuilder]

Je suis absolument certain, surtout à cause de la jointure, que rien ne garanti que les lignes seront retournées dans l'ordre de l'index de ta table 1, car si c'est la table2 qui est lue en premier (et donc les lignes retournées dans l'ordre de table2) alors les lignes de table1 seront dans le désordre.

PS : Et le "not in" peut être traduit par le SGBD par une jointure.

Ensuite, ton DDL est ce qu'il est aujourd'hui. Rien ne garanti que demain il n'y aura pas une autre colonne.
(ni même que l'index en cluster sera différent demain)

Et une requête qui change de résultat quand mon modifie un index ou un type de colonne, bah... non quoi... Je sais bien qu'il faut donner du boulot à l'équipe support mais quand même

[Kropernic]

Mmh ok...

Auriez-vous une vague idée du/des index/es que je devrais créer pour optimiser la vitesse de traitement de cette requête ?

J'ai toujours du mal pour déterminer cela... (le manque de pratique).

Sinon, je vais tacher de cogiter pour modifier la requête... Il y a p-e moyen de faire plus simple...

[StringBuilder]

C'est quoi l'algo de la requête ?

Car j'avoue que je m'y perd un peu...

[SQLpro]

Ca arrive vraiment que le SGBDR lise un index à l'envers ? 0_0

Non seulment il peut lire à l'envers, mais vu que c'est multithreadé il peut faire n lectures partielles...

On ne mélange JAMAIS le physique (index) avec la logique (requête), c'est au moteur de décider quel index il doit utiliser.

A +

[Rei Ichido]

J'ajouterai qu'en plus de tout ce qui a été déjà dit, il y a là une sous-requête, ce qui a des chances de produire un hash join, donc un ordre totalement aléatoire.

[iberserk]

Au passage vous parlez de l'utilisation de OUTER APPLY dans votre premier POST mais dans ce même POST vous collez une requête usant de CROSS APPLY ce qui est complétement différent!