と の 2 つのテーブルがtabA
あり、 からへtabB
の 1 対多の関係があります。私はクエリを持っています:tabA
tabB
SELECT * FROM `tabA` LEFT JOIN `tabB` ON `tabA`.`aID` = `tabB`.`aID`
返される行は、 から への参照tabA
ごとに複数の重複がある大きなセットです。tabB
tabA
GROUP BY
行を一意の要素に制限するために使用できることを認識していますが、関数tabA
を使用してカスタムフィールドを使用し、エスケープ用のGROUP_CONCAT
2 つの関数と組み合わせて使用しない限りREPLACE
(これはパフォーマンスに深刻な影響を与えます)、含まれる行の 1 つをすべて失います。tabB
. クエリの例は次のようになります。
SELECT `tabA`.*,
GROUP_CONCAT(REPLACE(REPLACE(`tabB`.`tabBCol1`, '/', '//'), ',', '/,')) AS `tabBCol`,
GROUP_CONCAT(REPLACE(REPLACE(`tabB`.`tabBCol2`, '/', '//'), ',', '/,')) AS `tabBCo2`
FROM `tabA`
LEFT JOIN `tabB` ON `tabA`.`aID` = `tabB`.`aID`
GROUP BY `tabA`.`aID`
そのクエリにより、LIMIT
構文を使用できるようになるため、(たとえば) 5 から始まる 5 つのエントリのみを表示できます (つまりLIMIT 5,5
)。これを前のクエリに適用すると、次の 5 つのクエリではなく、関連付けの数に基づくランダムなデータ セットが取得されます。
したがって、2 番目のクエリとは別に、関連付けを使用して行をフェッチする方法はありますが、LIMIT
構文の使用を許可し、過剰なREPLACE
関数のパフォーマンスへの影響はありませんか?
追加
各行に複数のサブクエリを使用できますが、最初のクエリをGROUP BY
構文で使用して (これによりWHERE
、関連付けに任意の条件を適用できます)、N+1 選択の問題を回避する方法を見つけようとしています (ただし、この例では、私のLIMIT
構文は ですLIMIT 5,5
。これをはるかに大きなLIMIT
s (一度に最大 1000 行) に適用します)。