有需求，给几百条记录疑似信息被外界通过某api探测出是否我行客户，进行了相关的诈骗。
需分析可能是那些api访问探测的。
数据仓库中五六千个api，就算定位含相关字段的接口也有近千个，并非每个映射成了某标准化字段，没有映射标准化的字段，都使用json嵌套放置在单独的一列了。
即需要标准化的用户id进行in查询，也需要在混合所有非标准化数据的那列进行 like查询，得到所有记录。
然后presto sql爆了compile failed。
怀疑是sql太长了，二分法、手动调整 or like 查询个数极限。然后减少其他字符的长度，例如 api in的查询 集合大小，再增加一个 or like 条件，还是会compile failed。
说明，有些查询引擎，不仅有长度限制、也有条件组合个数限制。
