多种场景下的融合搜索有什么比较合理的方案呢？

为了低耦合，建议分索引，问题2和3也没了。同时务必做好以下两点：
（1）保持好“一场景一索引”的原则。
（2）所有索引字段对齐，没有数据的字段置空而非null值。
不按上面做，后续会有以下痛点：
（1）“多场景一索引”很多人会有type区分索引，这样会导致查询时做不了以索引区分权重。比如你想让“联系人”权重更高，一索引情况下做不了（可以做，但比较麻烦）。
（2）多索引没对齐字段以及没有数据的字段不置空而是null值，查询时script_score会报错。比如_search/index1,index2时，index2里没有某个字段或某字段是null，script_score都会报错导致查询请求失败。
所以一开始就做好规范吧，曾ES接入过100+个场景的建议。

1. copy_to到一个新字段，或者查询用multi_match，匹配。已经有库，不想重建索引的话，只能使用multi_match。
2.不是很明白你的这个搜索范围是啥意思？每次搜索的字段组合不同吗？这样的话multi_match就可以，
3.量级不同，尽量别考虑这个的影响影响。ES数据是倒排索引，看你匹配的精细程度，应该考虑怎么分词。
 

问题有:
1. 不同数据独立索引，还是有一个`综合索引`？
楼主的意思我大概清楚了，
问题1,如果你们是数据的收集端，那么规范你们先定义好，
比如业务有
1,联系人
2,新闻
3,项目文档
三种业务都有如下数据字段:
联系人有用户名,地址
新闻有用户名(可能叫新闻发布者),地址
项目文档有用户名(项目管理者),地址
以后可能还要加入
4,司机
司机有,司机名字,地址
此时,是应该用一个索引接收所有业务数据,(包括新闻，联系人等)，还是针对每一种业务一个索引
 
我认为都可以，看怎么设计了，
1,如果数据量真的不大，全放到一个超级大索引中也行啊，分开不同索引到放也行啊,这样的话所有业务数据相互结合在一起，集群出问题，所有业务全挂了。
 
2,如果数据量非常大，那只能拆分，拆分小集群中，并且使用分开的索引(分开的索引页可以使用同一个名字，集群不一样就行)
每次增加一个业务，增加一个小集群,这样设计，也利于稳定性，相互之间不影响，一个小集群挂掉，不会影响其他所有的业务
 
如果是我设计，我更倾向于小集群，比较考虑到微服务，考虑到职责单一，不要堆积，堆积，堆积，膨胀，膨胀，膨胀,最后爆炸了。 
2. 不断有新场景引入的情况下，怎么控制搜索范围？
问题1应该说明白了。

3. 不同数据量级差异较大，如何设计索引切割比较合理？
问题1也说明白了。