2008-11-20 8 views
1

J'ai une requête SQL Informix qui retourne un ensemble de lignes. Il a été légèrement modifié pour la nouvelle version du site sur lequel nous travaillons et notre QA a remarqué que la nouvelle version renvoie des résultats différents. Après enquête, nous avons constaté que la seule différence entre deux requêtes était le nombre de champs retournés.Requête SQL Informix: deux requêtes similaires retournant des résultats différents

Les clauses FROM, WHERE et ORDER BY sont identiques et les noms de colonnes dans la partie SELECT n'ont pas affecté les résultats. C'était seulement le nombre de champs qui a causé le problème.

Des idées?

+0

Je pense que pour vraiment aider, nous aurions besoin de voir le SQL, la structure de la table, et peut-être quelques exemples de contenu? – toolkit

+0

@toolkit: Je comprends parfaitement votre point mais franchement je crois que le SQL n'est vraiment pas pertinent ici - comme je l'ai dit la requête est grande mais n'a rien à écrire à propos –

+0

Les informations standard nécessaires pour des problèmes comme celui-ci comprennent la version d'IDS que vous utilisez et la plate-forme sur laquelle vous l'utilisez. La version devrait être en trois parties, telles que 11.50.FC1. Les trois parties peuvent être importantes. –

Répondre

1

Le moteur Informix SQL utilise les indices sur les tables sur la base des colonnes que nous voulons récupérer. Lors de la récupération de différentes colonnes, nous utilisions des indices différents et obtenions donc les résultats dans un ordre différent.

2

Ajout de --+ ORDERED La directive join-order résout le problème en vous permettant d'obtenir vos résultats dans un ordre prévisible à chaque fois.

Les liens va à la description de la façon dont la directive fonctionne http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls1144.htm

Utilisez la directive ORDONNE ordre de jointure pour forcer l'optimiseur à se joindre à des tables ou vues dans l'ordre dans lequel ils apparaissent dans la clause FROM de la requête .

SELECT --+ ORDERED 
    name, title, salary, dname 
FROM dept, job, emp WHERE title = 'clerk' AND loc = 'Palo Alto' 
    AND emp.dno = dept.dno 
    AND emp.job= job.job; 
0

Je suppose que par «champs», vous voulez dire le nombre de lignes de données de sortie? D'après mon expérience, les gens utilisent des «champs» et des «colonnes» comme synonymes. Étant donné que les noms de la liste de sélection ne changeaient pas, vous n'aviez probablement que des différences dans le nombre de lignes renvoyées. Étant donné les mêmes tables, données d'entrée et requête, la taille et le contenu de l'ensemble de résultats doivent être les mêmes, quel que soit le plan de requête ou la version du serveur. Le séquencement de l'ensemble de résultats peut être différent à moins que vous imposiez un ordre sur les résultats, mais cela est légitime dans tout SGBD.

Si vous obtenez différentes tailles de jeux de résultats, vous devez probablement contacter le support technique IBM. Au moins un des ensembles de résultats est erroné, et les mauvais résultats sont toujours sérieux. Bien que des conseils puissent aider à améliorer les performances, les conseils standard de 'run UPDATE STATISTICS (avec les ensembles d'options appropriés)' aident généralement, ni la présence ni l'absence d'index ne doivent modifier le jeu de résultats lorsque les données sous-jacentes sont stables. . (Si les données changent, il existe une variété de problèmes et de complications à craindre.)

0

Je ne vois que deux explications à cela:

  1. Une fonction d'agrégat est utilisé, comme COUNT (DISTINCT colonne), ou
  2. les colonnes supplémentaires étant choisies sont d'une table qui est OUTER rejoint

Je comprends que vous ne souhaitez pas publier les définitions SQL et de table, mais cela ne les rend difficile à diagnostiquer.

Questions connexes