When writing the code reception today pass over the string '1,2,3,4,5,6', similar to the direct use of IN this case is invalid, the need to string into assembled into an array or list, then use mabatis the function foreach
<select id = "queryXXX",resultType = "XXX", paramterType = "java.lang.HashMap">
SELECT * FROM fast_input f where id in
<foreach item="item" index="index" collection="list" open="("
separator="," close=")">
#{item}
</foreach>
</select>
Or may be INSTR, FIND_IN_SET other functions, thereby exactly three test the efficiency of this function.
Built table:
CREATE TABLE `fast_input` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`content` varchar(100) DEFAULT NULL COMMENT '内容',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Data insertion cycle
INSERT INTO fast_input(content) SELECT content FROM fast_input
I used the 65000 data, respectively, execute the following statement
SELECT * FROM fast_input f where FIND_IN_SET ( id, '4,14,144');
Affected row: 0
Time: 0.022s
the SELECT * WHERE INSTR the FROM fast_input F (CONCAT ( ',', '4,14,144', ',' ), CONCAT ( ',', id, ','))> 0;
affected row: 0
time: 0.032s
the SELECT * WHERE ID in the FROM fast_input F ( '. 4', '14', '144');
affected rows: 0
Time: 0.001s
It can be seen, IN since a primary key index, maximum efficiency, and a method of rejection of the other two orders of magnitude, followed by the FIND_IN_SET, slowest INSTR. But there is a problem we note below:
SELECT * FROM fast_input f where FIND_IN_SET ( '4', id);
Affected row: 0
Time: 0.021s
the SELECT * WHERE the FIND_IN_SET the FROM fast_input F (ID, '. 4');
Affected row: 0
Time: 0.018s
The same FIND_IN_SET, different parameters position, also affect the efficiency, are interested can study at their own why.
PS: in practice, we can use the actual situation or FIND_IN_SET IN functions, a high efficiency, a convenient writing.