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

Bonjour,

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

Citation:

---

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

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

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

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

---