文中使用的Oracle版本为10g。

在真实的业务场景中往往很难避免有“in”条件查询的时候，但我们都知道用“in”做条件查询时SQL是一般不会走索引（某些新版数据库除外），那如果“in”含大量条件甚至超过1000条该怎么办呢（大部分数据库在基于性能方面考虑限制了“in”条件不能超过1000个）？下面将结合一个例子，给各位详述我的解决方案。

后台输出截获的SQL脚本如下（因可能涉及敏感信息，为此将部分字段表述进行转换）：

SELECT *  FROM (SELECT SHOWDATA.*, ROWNUM RN          FROM (SELECT DISTINCT A.OWNER_PHONE,                                GP.NAME,                                A.CALLTYPE AS CALLEDTYPE,                                A.TRANS_PHONE,                                A.TRANS_NAME NAMES,                                A.TRANS_CALLED_INFO,                                TO_CHAR(A.TRANS_STARTTIME,'yyyy-mm-dd HH24:mi:ss') AS TRANS_STARTTIME,                                TO_CHAR(A.TRANS_STARTTIME, 'HH24') TRANS_HH,                                A.TRANS_DURATION,                                A.AR,                                A.LAC,                                A.CS,                                A.LN,                                A.CB,                                A.CL,                                A.CC,                                A.CA,                                A.OI,                                A.CI,                                A.TL,                                A.TLA,                                A.TCL,                                A.TCLA,                                A.TA,                                A.ISR,                                A.ISO                 FROM GPB A                 INNER JOIN GPBI GP ON A.PBII = GP.ID                 WHERE A.IS = 0                   AND A.TRANS_STARTTIME BETWEEN                       TO_DATE('2015-09-09 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND                       TO_DATE('2016-09-09 00:00:59', 'YYYY-MM-DD HH24:MI:SS')                   AND A.OWNER_PHONE IN (15000000000, 15100000000, 15200000000, ...)                 ORDER BY TRANS_STARTTIME DESC nulls last) 		SHOWDATA) WHERE RN > 0 AND RN <= 100

以上SQL有好几处地方可以优化但性能瓶颈在于“in”查询。以上看到的脚本内容是经过性能排查后截录的脚本片段，真实的脚本足够翻好几页（真想不明白之前写这个脚本的人是怎么想的）。

言归正传，这语句给我感觉：

1) 查询条件受到限制，最多只能查询1000个手机号码；

2) 由于使用“in”查询，这里OWNER_PHONE字段不能使用索引；

3) ORDER BY在完成“in”操作后还需进行一次全表扫描排序，这个也是另一个性能消耗点；

4) 最讽刺的是GPB 和 GPBI两个表前者是亿级表，后者是万级表，在INNER JOIN后最终只需要展示前100条数据，这前面大量运算有点浪费；

既然这样先将“in”查询问题先解决，这里我分成3步：

1. 建立一个TYPES（tabletype）

这个TYPE是一个TABLE类型的，代码如下：

CREATE OR REPLACE TYPE TABLETYPE AS TABLE OF VARCHAR2(32676);

不说废话，上代码：

CREATE OR REPLACE FUNCTION STRSPLIT (p_list CLOB, p_sep VARCHAR2 := ',')    RETURN tabletype    PIPELINED IS    l_idx    PLS_INTEGER;    v_list   VARCHAR2 (32676) := trim(replace(p_list,chr(10),'')); BEGIN    LOOP       l_idx   := INSTR (v_list, p_sep);       IF l_idx > 0       THEN          PIPE ROW (SUBSTR (v_list, 1, l_idx - 1));          v_list   := SUBSTR (v_list, l_idx + LENGTH (p_sep));       ELSE          PIPE ROW (v_list);          EXIT;       END IF;    END LOOP; END;

这个关于Oracle的字符串分割函数网上一搜一大把，各位酌情参考就可以了。函数生成后通过：

SELECT * FROM TABLE(STRSPLIT(‘A,B,C,D,E’)); 

得到一个虚拟的表。

3. 改造原SQL脚本

SELECT *  FROM (SELECT SHOWDATA.*, ROWNUM RN          FROM (SELECT DISTINCT A.OWNER_PHONE,                                GP.NAME,                                A.CALLTYPE AS CALLEDTYPE,                                A.TRANS_PHONE,                                A.TRANS_NAME NAMES,                                A.TRANS_CALLED_INFO,                                TO_CHAR(A.TRANS_STARTTIME,'yyyy-mm-dd HH24:mi:ss') AS TRANS_STARTTIME,                                TO_CHAR(A.TRANS_STARTTIME, 'HH24') TRANS_HH,                                A.TRANS_DURATION,                                A.AR,                                A.LAC,                                A.CS,                                A.LN,                                A.CB,                                A.CL,                                A.CC,                                A.CA,                                A.OI,                                A.CI,                                A.TL,                                A.TLA,                                A.TCL,                                A.TCLA,                                A.TA,                                A.ISR,                                A.ISO                 FROM GPB A                 INNER JOIN GPBI GP ON A.PBII = GP.ID                 INNER JOIN (                   SELECT INN.COLUMN_VALUE AS IN_DATA        							FROM (SELECT '' AS COLUMN_VALUE FROM DUAL WHERE 1 > 2              								UNION ALL              							    SELECT * FROM TABLE(STRSPLIT('15000000000,15100000000,...'))              								UNION ALL              							    SELECT * FROM TABLE(STRSPLIT('15200000000,15300000000,...'))              								UNION ALL              							    ......      								) INN      						) B ON A.OWNER_PHONE = B.IN_DATA                 WHERE A.IS = 0                   AND A.TRANS_STARTTIME BETWEEN                       TO_DATE('2015-09-09 00:00:00', 'YYYY-MM-DD HH24:MI:SS') AND                       TO_DATE('2016-09-09 00:00:59', 'YYYY-MM-DD HH24:MI:SS')                   AND A.OWNER_PHONE IN (15000000000, 15100000000, 15200000000, ...)                 ORDER BY TRANS_STARTTIME DESC nulls last) 		SHOWDATA) WHERE RN > 0 AND RN <= 100

这里用虚拟表进行内连接可以代替“in”操作，SELECT … UNION ALL 这部分内容通过MyBatis进行循环拼接也是可以实现的。由于不想在字符串末尾再删除UNION ALL字符，因此在查询开头加上一个查询DUAL表的操作并判断1>2即可。

动态条件内容将在Java内进行原数据的重组。Oracle自定义函数中参数内容不能太长（函数字段有长度限制），因此在Java中进行字符串长度限制分割，分割内容将保存到集合（List）中，通过参数传入DAO并在MyBatis中进行循环二次拼接。

这种方法无论需要“in”条件是多少，即使个数超过1000的情况下也是可以查询的，同时OWNER_PHONE字段可走索引。

具体查询性能对比如下：

改造前改造后

同样是查询前100条数据，前者是16.475秒，而后者是1.841秒，可以看出查询速度的差异。

最后附上Java和MyBatis的代码，如下图：

这根据长度切割数据集的代码虽然不影响使用但有待改进ε=(´ο｀*)))唉。

至于MyBatis就还是那样了。