2

これが私の疑似クエリです：

SELECT col1, col2 FROM table WHERE number IN(number1,number2,number3);

例

SELECT name, description FROM products WHERE 5 IN(category_id);

注: テーブルの行の 1 つにcategory_id = 2,5,7があると仮定しましょう

問題

私のクエリは、次のように行のコンマ区切りセットの先頭に「5」がある場合に機能します: 5,2,7 しかし、行が 5 以外で始まる場合、同じクエリは結果を返しません。

さまざまなシナリオを試してみましたが、mysql がコンマに遭遇すると、コンマで区切られた数字への一致をチェックしていないように常に見えます。

適切にフォーマットされたカンマ区切りの文字列や照合順序など、意味のあるものはすべてチェックしました。この時点で私を困惑させています。解決策はありますか？

FIND_IN_SET()私が使用し、それが完璧に機能したことに注意してください。IN()とはいえ、何が本当の問題なのか分からないまま捨ててしまうのはもったいないです。最初の遭遇で止まるのはなぜですか fa カンマ.

4

3 に答える 3

3

INカンマで区切られた単一の文字列値ではなく、一連の値に対して機能します。IN に指定された個々の値は、セット内の1 つの要素です。

MySQL は、ここで使用できる非標準FIND_IN_SET(str, strlist)関数を提供しますが、適切なリレーショナル データベース設計ではフィールドを正規化する必要があります。

文字列 str が N 個の部分文字列で構成される文字列リスト strlist にある場合、1 から N の範囲の値を返します。文字列リストは、「,」文字で区切られた部分文字列で構成される文字列です。

例：

WHERE FIND_IN_SET('5', category_id)

1 つの問題は、正規化を破り、参照整合性を無視することに加えて、FIND_IN_SETはインデックスを使用できないため、カーディナリティの高いセレクターとして使用するとスケーラブルではないことです。

FIND_IN_SET() と IN()も参照してください

于 2014-09-29T02:01:48.257 に答える
2

編集この回答の式の例は、完全に文字列コンテキスト、つまり文字データ型の比較に基づいています。これらの例では、暗黙的なデータ型変換、および文字列から数値への変換の風変わりな MySQL セマンティクスを考慮していません。たとえば'2,5,7'+0、整数値 2 に評価されます。その動作のデモンストレーションについては、Bohemian からの優れた回答を参照してください。)

表の行にはカテゴリ値があります '2,5,7'。それは文字列値です。

表現：

'5' IN ('2,5,7')

に等しい

'5' = '2,5,7'

文字列値内のカンマは、SQL テキストとして認識されず、文字列内の文字です。

で探している結果を得るにはIN、次のような式が必要です。

'5' IN ('2','5','7')

これは、SQL テキストの一部であるカンマで区切られた 3 つの個別の値です。これは次と同等です:

( '5' = '2'  OR '5' = '5' OR '5' = '7' )

あなたが尋ねた質問に答えるには：

Q: コンマの最初の遭遇で停止するのはなぜですか?

A:最初のカンマで止まりません。文字列全体を単一の文字列として比較します。この式でも同じ結果が得られます。

'5' IN ('5,2,7')

これは、式 '5' = '5,2,7'` と同等であり、比較される 2 つの文字列が等しくないため、FALSE を返します。

(編集:上記の例は文字列比較に基づいています。数値コンテキストでは、文字列'5,2,7'は数値 5 に評価されます。

その場合、最初のコンマで停止するのはまだではなく、IN「最初のコンマで停止する」のは文字列から数値への暗黙的な変換です。(コンマだけではなく、文字列を数値に変換できなくなった場所で遭遇する任意の文字であり、括弧、「#」、「b」などの可能性があります。)

結論:比較演算子は、IN文字列内のコンマ文字についてネズミの @ss を与えません。これらは、文字列内の単なる文字です。文字列値内のコンマは、SQL テキストの一部として解釈されません。

于 2014-09-29T02:09:26.130 に答える