今天和一业务端兄弟一同修改了一下我厂一个索引的查询模板，其中涉及到一个Bool Query中使用到的should查询，发生了一些有趣的现象，继而翻查文档发现这个确实是 ES中Bool should的设定，因此记录下来供大家参考。
这里先说明一下，我们出现这个问题是因为我们用的是ES的search template 并且大量使用了mustache语法去拼凑查询体造成的，如果你使用的是Transport Client并且你的程序能用代码生成完美的DSL 的话那么你看应该不会遇到我这个tricky的问题，不需要再往下看了 :)
首先我们先创建一个很简单的测试index, 里面有一些简单的字段，如id，学号，性别，家乡等，并创建了4条测试数据
PUT should_test/item/1
{
"id" : 1,
"student_no": 111,
"sex":"male",
"home":"guangzhou"
}
PUT should_test/item/2
{
"id" : 2,
"student_no": 222,
"sex":"male",
"home":"beijing"
}
PUT should_test/item/3
{
"id" : 3,
"student_no": 333,
"sex":"female",
"home":"shanghai"
}
PUT should_test/item/4
{
"id" : 4,
"student_no": 444,
"sex":"female",
"home":"shenzhen"
}
好，假设我们现在想找出住在 不同地方 的男同学，由于我之前说了，我们采用的是mustache模板写的，因此我们生成的查询模板大概是这样的
第一个 id = -99999 的查询是因为我们希望它是永假，这样只要任意一个for_home_list 命中就会搜索出来，并且在 for_home_list 大于0 时能够很好工作。
问题就出在了：业务方可能一个都不传，那么语义可能就变成了：“查找男生“，这样就造成了一个这样的查询：
这就有点奇怪了，按道理 should只是OR关系，应该是可有可无才对，后来再试试 加上"minimum_should_match" : 1，还是无果，最后在官方文档上找到一句说明：
也就是说，只要你的bool should 是放在 filter的context下的话，那么不管怎样一定要有至少一条clause 是要真的。
再试另外一种写法
那么就是说我这个写法不行了，那么把原来的查询模板改改，改成这样试试看？
很悲剧的，这样写其实在for_home_list为空的时候还是不行，因为我们设定了minimum_should_match 一定要为2，因此在list为空是无法实现的
而用永假的写法来想办法缩小范围，其实还是不行，因为这样还是会把结果集扩大了，由此也可以看出，同样的一个Bool 的should clause,放在 filter 里面和外面是不一样的行为。
那我非要用mustache 语法写这种蛋疼的template怎么办呢？
好吧，下面是一种蛋疼的写法，至少，它work了，他能完成的语义是：如果传了城市，那么，搜索出任意list中的城市的学生，如果不传，那么请忽略这个过滤条件
本文写给那些同样suffer mustache蛋疼语法的默默写着template的那些兄弟们。。。
完！
