hive 十几个like 如何优化

在我们工作中，其实经常需要使用这种耐克来进行模糊查找，比如说我这里有一张订单表，然后里面有一个公司名字，我现在需要支持按公司名字来找订单，那么对于客户而言，他肯定会输入腾讯、百度、京东啊这些中间的一部分来进行查找。 对我们后端的接口，后端的 c 口而言，你就必须支持这种左右两边都是模糊查找的情况。那如果这么写的话呢，就算我们在 呃 order 是表里面去创建的 company name 的一个缩影啊，比如说我这里就已经创建好了，那么我们上面的这个搜狗呢？它其实也不会走这个缩影， 因为他不符合我们的最左前缀原则吗？等于这边是百门号啊，那么怎么优化呢啊？我们一般啊，我们肯定先尽量的 去看能不能利用我们的锁引条件下推，什么意思呢？比如说我们再看我这个表里面呢，其实还有一个字段，那我们来看一下，还有一个 crea 的字段，就表示这个订单的创建时间。那假如我现在再来创建一个锁引，大家可以看一下下边的 这个缩影啊，它是针对 created at 和 company name 去创建了一个联合缩影，这一 company name 在后面。 好，那么现在假如我还是来找订单，但是我比如说就查今天的订单的话，那么其实呃在后面再跟上公司名字的话，我们再来试一下，你看他就能够走到我们刚刚所创建的这个联合。所以好， 那么注意后面这个 x 球，这里呢就有一个 using index condition， 这就表示它利用了我们的所引调， 所以条件什么意思呢？是这个意思，我们知道这一个联合，所以他其实对应的就是一颗比较树啊，那么我当我们执行这个 circle 的时候呢，他会先按照 呃这个 creat 艾特的条件啊，就比如说是今天吗？那么他就会根据我们的毕加数去找，找到毕加数的符合当前这个日期的所有的叶子界面。拿到叶子界面之后啊，再会根据你 company 内 你这里给的条件去进行筛选，从叶子间里面再筛选出来一部分，然后再把这一部分的组件 id 拿出来，去我们的组件缩影上面再去回表。 所以呢整个过程啊，我们的 combating 内，他其实还是起到了一定的作用的啊，因为这样子的话呢，他相当于我如果加上这个条件或者说这个，所以里面包含了这个字段，其他这种回表的时候 是能够呃回来的次数能够减少的，从而呢能够提高我们的效率。所以就是呃，我们在支持这种查询功能的时候呢，可以考虑一下，就算你这里是呃左右两边都是模糊查询，那么其实也不说一定不能把它放到所以里面去，就是放进去 可能还是会有一些些好处的好吧，当然在我们实训工作中间啊，假设我们就根本没办法再再针对看不见那样去签什么联合，所以的话，那么这种就没有什么办法，因为他没办法去做，所以当然如果说你呃还是当然你还是可以利用一些其他的 呃，比如说一些覆盖缩影啊啥的，那这样子的话呢，其实还是能够利用的，但是这种出来的效率也没有那么高，也没有那么高，因为我们一般其实你肯定会除开 company 链字段之外，你可以赶快去查一些其他的字， 那这样子的话也没有也没有办法利用我们的锁印扫描啊，所以就这种。当然我们实在不行的话呢，你可以先试一下 miceocle 里面的全文锁印啊。全文锁印呢，它主要就是用来支持这种模糊查询的，如果说你发现 它全文缩影不太好的话呢，我们再去考虑呃 e s 啊之类的。