今日のコード受信を書くときに、この場合は、無効であるINの直接の使用と同様、文字列「1,2,3,4,5,6」、上を通過、配列またはリストに組み立てるに文字列への必要性は、その後、使用関数のforeachをmabatis
<= "XXX"を選択し、ID = "queryXXX"、resultTypeと、paramterType = "java.lang.HashMap">
SELECT * FROM fast_input Fどこのid
<foreachの項目= "項目"インデックス= "インデックス"コレクション= "リスト"オープン= "（"
セパレータ= ""クローズ= "）">
＃{項目}
</ foreachの>
</選択>
またはINSTR、FIND_IN_SET他の機能は、この機能のそれによって正確に3つのテスト効率であってもよいです。
内蔵のテーブル：
CREATE TABLEの`fast_input`（
` id`はint（11）NOT NULL AUTO_INCREMENTのCOMMENT '主键'、
`content`のVARCHAR（100）DEFAULT NULLのコメント'内容'、
PRIMARY KEY（` id`）
）ENGINE = InnoDBのデフォルトの文字セット= UTF8。
データ挿入サイクル
fast_input。INSERT INTO（コンテンツ）fast_input FROM SELECTコンテンツ
私は、次の文を実行し、それぞれ、65000件のデータを使用しました
FIND_IN_SET（F fast_input SELECT * FROM ; ID、 '4,14,144'）
0：影響を受ける行
時間：0.022s
SELECT * FROM INSTR fast_input F（CONCAT（ ' ' '4,14,144'、'、' ）、CONCAT（」 ' ID、'、 '））> 0;
影響を受けた行：0
時間：0.032s
' 4' SELECT * WHERE F（fast_inputからID、 '14'、 '144'）。
影響を受けた行：0
時間：0.001s
これはFIND_IN_SET、最も遅いINSTR続いて、主キーインデックス、最大効率、および大きさの他の二桁の拒絶の方法ので、見INすることができます。しかし、我々は以下の注意問題があります：
SELECT * fast_input FからここFIND_IN_SET（ 4 ''、ID）;
影響を受ける行：0
時間：0.021s
SELECT * FROM FIND_IN_SET F（ID、4' 」）fast_input;
影響を受ける行：0
時間：0.018s
同じFIND_IN_SET、異なるパラメータの位置、また効率に影響を与え、なぜ自分自身で勉強することができます興味を持っています。
PS：実際には、我々は実際の状況やFIND_IN_SET機能では、高効率、便利な書き込みを使用することができます。