MySQL のドキュメントを読んでも、phpMyAdmin でのこれら 2 つのクエリの違いを説明できません。
SELECT * FROM f_ean GROUP BY ean HAVING type = 'media'
--> 57059 件の結果が得られます
SELECT ean, type FROM f_ean GROUP BY ean HAVING type = 'media'
--> 73201 件の結果が得られます
異なる列を表示するだけで、クエリの結果の数がどのように異なるのでしょうか?
レコードをフィルタリングしようとしている場合WHEREではなく、を使用する必要があります。グループ化と並べ替えが行われた後にフィルターを適用するために使用されます。HAVINGHAVING
とにかく、問題は MySQL が をどのように使用するかにありますGROUP BY。GROUP BY集約とともに使用する必要があります。MySQL は利便性のために機能を拡張します。列の並べ替えとグループ化の方法が原因で、異なる結果が表示されます。
MySQL は の使用を拡張して、選択リストが句
GROUP BYで指定されていない非集計列を参照できるようにします。GROUP BYこれは、前述のクエリが MySQL で有効であることを意味します。この機能を使用すると、不要な列の並べ替えやグループ化を回避してパフォーマンスを向上させることができます。ただし、これは主に、 で指定されていない各非集計列のすべての値がGROUP BY各グループで同じ場合に役立ちます。
の拡張子をGROUP BY参照してください。
MySQL は、WHERE 句または AGGREGATE 関数 (または場合によっては JOIN 条件) を使用して指定しない限り、グループ化されていない列のどの値が結果セットに含まれるかを保証しません。
含める値を選択する方法を示すドキュメントを見たことがないので、少し推測すると、最も関連性の高いインデックス内で行の順序を使用していると思います。
したがって、colA、colZ の SELECT と * の SELECT は、MySQL をトリガーして、結果セットをコンパイルし、行の「認識された」順序を変更し、異なる値を表示するときに、さまざまなインデックスを利用する可能性があると想定するのが合理的です。
WHERE 条件を使用している場合、これは問題になりません。グループ化の前に WHERE 条件が適用されます。ただし、グループ化されていない列で HAVING 条件を使用しており、その列に潜在的な変動があるため、表示されている不一致は大部分が予想される動作です。