2010-11-11 6 views

Répondre

4

C'est mieux si vous nous dire ce que vous utilisez SGBDR, mais ...

1 - Ne pas faire SELECT *. Spécifiez les colonnes dont vous avez besoin Moins de données = requête plus rapide

2 - Pour l'indexation, assurez-vous d'avoir un index sur CNIC. Vous voulez également un bon index clusterisé sur une clé primaire (de préférence quelque chose comme un numéro ID)

3 - Vous mettez le nombre entre guillemets simples ' ' qui indique que vous pouvez l'avoir comme une colonne varchar. Si ce sera toujours NUMERIC, il doit s'agir d'un type de données int/bigint. Cela prend moins de place et sera plus rapide à récupérer et à indexer.

+0

hmmm, goood. +1 pour 'Moins de données = requête plus rapide' :) –

+1

pour développer votre # 1, si l'OP peut supprimer le" * "avec une petite liste de colonnes (et selon la base de données, tous ne supportent pas cela), vous pouvez créer un colonnes index et INCLUDE utilisées dans la requête. C'est ce qu'on appelle un indice de couverture, et peut accélérer l'utilisation d'un index non cluster. –

+0

@KM - Bonne suggestion. – JNK

2

Créer un index sur CNIC:

CREATE INDEX ix_employee_cnic ON employee (cnic) 
1

La première chose, que je vois cette colonne sera utilisée pour stocker nos cartes d'identité, vous pouvez faire votre coulmn de type int plutôt que varchar ou nvarchar que la recherche sera plus rapide sur un type entier par rapport à varchar ou nvarchar.

Deuxièmement, utiliser with (no lock), comme

select * from Employee with (nolock) where CNIC = 'some-CNIC-number' 

Ceci est de minimiser les chances d'une impasse.

Questions connexes