FAQ FirebirdConsultez toutes les FAQ

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:

1
2
3
4
5
6
7
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);

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/

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/

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/

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/

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 :

1
2
3
4
WHERE x = 1 
WHERE x > 10 
WHERE x IS NULL 
WHERE x BETWEEN 1 AND 10

1
2
3
4
WHERE x <> 1 
WHERE x NOT > 10 
WHERE x IS NOT NULL 
WHERE x NOT BETWEEN 1 AND 10

WHERE x NOT > 10

WHERE x <= 10