Bei den nichtpassenden Join Bedingungen hat die Database Engine ja eigentlich keine Möglichkeit Zugriffspfade zu nutzen, da hilft nur Redundanz (zusätzliches Feld mit passendem Datentyp), aber bei dem angeführten Beispiel ist das ein schlichtes Armutszeugnis und lässt mich bezweifeln ob es eine neu Database Engine gibt, oder es sich um ein Rebranding durch das Marketing handelt (früher nannte man das alter Wein in neuen Schläuchen).
Das Verhältnis zwischen den Debug Meldungen, dem Database Monitor und dem Visual Explain ist einfach benannt: das basiert alles auf den Daten, die der Database Monitor liefert und wenn es Abweichungen bei verschiedenen Ablaufumgebungen gibt, dann muss man genau auf den Daten von Laufzeitmessungen aufbauen, alles ander ist Quark. Ob man dann lieber liest, oder lieber Bildchen anschaut, das ist pure Geschmacksache; ich bevorzuge lesen und selber analysieren, wenn visual explain schlaue Vorschläge macht, dann frage ich mich warum er die nicht gleich der Query engine macht!!!
Bei Oracle kann man sowas konfigurieren und selbst MySQL geht diesen Weg!

Dieter

Zitat Zitat von Fuerchau
Da kann ich Dieter nur zustimmen.
Der Tablescan / Indexaufbau erfolgt auf Basis des Feldes der Where-Bestimmung.
Das gleiche gilt übrigens auch, wenn bei einer Join-Beziehung die Feldtypen nicht zueinander passen. Auch in diesem Fall konvertiert der Optimizer die Datenbank (bzw. Index-Anlage) und nicht intern nur das Feld !!!

Um also performante Ergebnisse zu erzielen, ist es UNABDINGBAR zumindest die Feldtypen von Join und Where zu Programmvariablen (Parametern) abzugleichen bevor man mit irgendwelchen Tools (Visualirgendwas) an weitere Analysen geht.
Zumindest hierbei konnte ich mich IMMER auf die Debug-Angaben des Joblog's verlassen.