文中使用的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);

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就还是那样了。