IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
logo
Sommaire > Performances
        Pourquoi ma requête utilisant IN ou NOT IN est-elle lente ?
        Pourquoi ma requête est plus lente à l'intérieur d'une vue ?
        Pourquoi le cache de la base de données n'est pas utilisé par Firebird avec mes applications web?
        Pourquoi MAX(champ de clé primaire) n'utilise pas l'index ?
        Pourquoi LIKE 'A%' ne se comporte pas toujours comme STARTING WITH 'A'?
        Pourquoi Firebird n'utilise pas d'index en cas de requête avec NOT quelque chose?



Pourquoi ma requête utilisant IN ou NOT IN est-elle lente ?
auteur : SergioMaster
Cela vient de l'optimisateur de requête. Dans les nouvelles versions de Firebird le problème avec IN est réglé, celui avec NOT IN persiste.
Dans tous les cas, il est plus sûr et souvent plus rapide d'utiliser EXISTS et NOT EXISTS à la place.
Chaque requête IN, NOT IN peut être réécrite en utilisant EXISTS ou NOT EXISTS.
Exemple:

SELECT * FROM employee e
WHERE e.emp_no IN (SELECT s.emp_no FROM salary_history s);

-- Réécrite avec EXISTS:

SELECT * FROM employee e
WHERE EXISTS (SELECT 1 FROM salary_history s WHERE e.emp_no = s.emp_no);
Traduction réalisée depuis http://www.firebirdfaq.org/faq37/


Pourquoi ma requête est plus lente à l'intérieur d'une vue ?
auteur : SergioMaster
Jusqu'à la version 2.0, l'optimisateur de requête de Firebird n'était pas très bon avec les vues et utilisait rarement les index.
Vérifiez le plan de requête quand vous utilisez un SELECT dans une vue et vous pointerez rapidement le problème.
Il est donc fortement recommandé d'utiliser au minimum Firebird 2.0. Si vous devez utiliser Firebird 1.x, la seule manière d'accélérer est d'écrire une procédure stockée prenant les valeurs de la clause WHERE comme paramètres et ainsi utiliser l'index approprié.
Traduction réalisée depuis http://www.firebirdfaq.org/faq276/


Pourquoi le cache de la base de données n'est pas utilisé par Firebird avec mes applications web?
auteur : SergioMaster
Firebird charge la page cache à la première connexion à la base, quand le dernier client se déconnecte, la mémoire utilisée par le cache se libère.
Cela peut être problématique avec des applications web (PHP, ASP, ...) qui ont des transactions courtes du style 'connexion-exécution-déconnexion',
Mais aussi avec des applications courantes qui ne gardent pas la connexion ouverte.
Le problème est inconnu sous Linux puisque ce système d'exploitation met en cache le système de fichier même après sortie de l'application.
Cependant, sous Windows, la mémoire est libérée de suite, et les données doivent être rechargées du disque à chaque fois.
En cas d'utilisation de Windows, vous pouvez contourner ce problème en ayant un connexion simple, ne faisant rien : Faites juste une connexion, rien de plus - ne démarrez pas de transaction car cela augmenterai le compteur de transaction .
Prenez note que de nombreux outils ou bibliothèque démarrent une transaction implicite au log in.

Sous Linux, il sera judicieux de réduire la valeur de DefaultDbCachePages dans le fichier firebird.conf pour diminuer le nombre de pages pré-chargées à chaque connexion - le système de fichier mettra en cache les plus utilisées de toute manière.
Traduction réalisée depuis http://www.firebirdfaq.org/faq302/


Pourquoi MAX(champ de clé primaire) n'utilise pas l'index ?
auteur : SergioMaster
C'est parce que les clés primaires utilisent un index en ordre ascendant et que MAX utilise seulement les index descendants.
Par exemple, si vous essayez d'obtenir MIN(champ de clé primaire) l'index sera utilisé.
Si vous avez de fréquentes requêtes utilisant MAX, il sera judicieux de créer un autre index, d'ordre descendant (DESC,DESCENDING) sur la colonne de la clé primaire.
Traduction réalisée depuis http://www.firebirdfaq.org/faq205/


Pourquoi LIKE 'A%' ne se comporte pas toujours comme STARTING WITH 'A'?
auteur : SergioMaster
C'est un problème connu de l'optimisateur de Firebird corrigé à partir de la version Firebird 2.1.
Traduction réalisée depuis http://www.firebirdfaq.org/faq308/


Pourquoi Firebird n'utilise pas d'index en cas de requête avec NOT quelque chose?
auteur : SergioMaster
C'est parce que les index sont utilisés par Firebird pour rechercher des enregistrements correspondant aux critères.
Quand vous indiquez que vous ne voulez pas les enregistrements correspondant aux critères l'index est inutile: il aurait à chercher tous les enregistrements que vous ne voulez pas et ensuite récupérer les autres en utilisant une recherche NATURAL.
Il est donc meilleur de faire une recherche totale dans la table une seule fois.

Peut-être aurez-vous des situations où vous n'avez que quelques enregistrements ne correspondant pas au critère,
ou seulement peu qui le remplissent, mais Firebird ne peut pas le savoir - il ne connait que la sélectivité de l'index et les termes de votre requête.
Donc, pour faire court, les critères suivant (en considérant que le champ x soit indexé) utiliseront l'index :

WHERE x = 1
WHERE x > 10
WHERE x IS NULL
WHERE x BETWEEN 1 AND 10
et les suivants, non :

WHERE x <> 1
WHERE x NOT > 10
WHERE x IS NOT NULL
WHERE x NOT BETWEEN 1 AND 10
Comme vous le constaterez, la négation d'une expression (NOT) des opérateurs 'plus petit que' et 'plus grand que' peut être ré-écrite pour obtenir l'utilisation d'un index.
Plutôt que :

WHERE x NOT > 10
écrivez
WHERE x <= 10
Traduction réalisée depuis http://www.firebirdfaq.org/faq216/



Consultez les autres F.A.Q's


Valid XHTML 1.1!Valid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2009 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.