ASE15-Index non-utilisé qd utilise variables dans WHERE clause

[vinceroi]

Bonjour,

Sur plusieurs serveurs ASE 15.5, nous avons une table T de 5 Millions de rows avec le DDL suivant:

create table T (
UID int not null ,
logOnDtm datetime not null ,
logOffDtm datetime null ,
termID varchar(20) not null ,
autoSignOff varchar(1) null ,
sessionID varchar(255) null
)
lock allpages

le showplan montre que la requete ci-dessous utilise l'index:

Code :

SELECT * FROM T WHERE  T.logOnDtm >= '20120309' AND T.logOnDtm < '20120310'

Mais que la requete ci-dessous n'utilise pas l'index:

Code :

1
2
3
4
5
6
7
declare @startDtm datetime
declare @endDtm datetime
 
SELECT @startDtm = '20120309'
SELECT @endDtm = '20120310'
 
SELECT * FROM T WHERE  T.logOnDtm >= @startDtm AND T.logOnDtm < @endDtm

Pourquoi l'index n'est pas utilisé par l'optimizer dans le 2ieme cas?

Note1: forcer l'index fonctionne = l'index est utilisé
Note2: j'ai essaye plusieurs formats de dates et même de char() sans succes.

Merci
Vincent

[mpeppler]

Lorsqu'on n'est pas dans une proc stockée ASE ne fait pas d'interpolation des variables, et donc va utiliser une heuristique assez basique pour déterminer si les indexes sont intéressants.

En général la seule solution est de forcer l'index.

Michael

[vinceroi]

Merci Michael.

Je viens de tester ce code dans une stored procedure et l'index n'est malheureusement pas utilisé.

En forcant l'index ca fonctionne mais je n'arrive pas a comprendre pourquoi l'optimizer n'essaie pas d'abord d'evaluer un plan avec l'index d'autant que les variables sont definis comme variables statiques au debut du code. Ce n'est pas comme si les variables changeaient tout le temps comme dans un curseur.
Est-ce que le parser Sybase ne commence-t-il par remplacer les valeurs statiques dans le code avant d'evaluer le query plan d'execution?

Merci,
Vincent

[vinceroi]

J'ai supprimé les deux index suivants que j'avais sur la table:

Code :

1
2
3
4
5
 
index_name            index_keys     index_description 
 --------------------- -------------- -----------------
 TIndex1  UID, logOnDtm clustered                      
 TIndex2  logOnDtm      nonclustered

Puis j'ai re-créé un index clusterisé sur le champ date "logOnDtm"
=> cela fonctionne desormais = la query utilise index

La question est donc:
- est-ce un probleme de design d'index de la part du developeur?
- est-ce que mon index clusterise etait trop defragmenté alors que j'utilisais l'index non-clusterisé?

Le cluster ratio des 2 index etaient:

Code :

1
2
3
4
5
6
7
8
 
SELECT derived_stat("T", "TIndex1", "dpcr");
 --------------------
             0.216365
 
SELECT derived_stat("T", "TIndex2", "dpcr");
 --------------------
             0.006302