文中使用的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”查询。以上看到的脚本内容是经过性能排查后截录的脚本片段，真实的脚本足够翻好几页（真想不明白之前写这个脚本的人是怎么想的）。
言归正传，这语句给我感觉：
-
查询条件受到限制，最多只能查询1000个手机号码；
-
由于使用“in”查询，这里OWNER_PHONE字段不能使用索引；
-
ORDER BY在完成“in”操作后还需进行一次全表扫描排序，这个也是另一个性能消耗点；
-
最讽刺的是GPB 和 GPBI两个表前者是亿级表，后者是万级表，在INNER JOIN后最终只需要展示前100条数据，这前面大量运算有点浪费；
既然这样先将“in”查询问题先解决，这里我分成3步：
1. 建立一个TYPES（tabletype）
这个TYPE是一个TABLE类型的，代码如下：
CREATE OR REPLACE TYPE TABLETYPE AS TABLE OF VARCHAR2(32676);
2. 建立自定义函数STRSPLIT以PIPE ROW返回
不说废话，上代码：
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就还是那样了。