php+Mysql 优化，百万至千万级快速分页
创新互联来电联系：18980820575，为您提供成都网站建设网页设计及定制高端网站建设服务，创新互联网页制作领域10多年，包括搬家公司等多个方面拥有丰富建站经验，选择创新互联，为企业保驾护航！
MySql 性能到底能有多高？用了php半年多，真正如此深入的去思考这个问题还是从前天开始。有过痛苦有过绝望，到现在充满信心！MySql 这个数据库绝对是适合dba级的高手去玩的，一般做一点1万篇新闻的小型系统怎么写都可以，用xx框架可以实现快速开发。可是数据量到了10万，百万至千万，他的性能还能那么高吗？一点小小的失误，可能造成整个系统的改写，甚至更本系统无法正常运行！好了，不那么多废话了。用事实说话，看例子：
数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用text, id 是逐渐，vtype是tinyint，vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。
最后collect 为 10万条记录，数据库表占用硬盘1.6G。OK ,看下面这条sql语句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 从9万条开始分页，结果？
8-9秒完成，my god 哪出问题了？？？？其实要优化这条数据，网上找得到答案。看下面一条语句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。为什么？因为用了id主键做索引当然快。网上的改法是：
select id,title from collect where id=(select id from collect order by id limit 90000,1) limit 10;
这就是用了id做索引的结果。可是问题复杂那么一点点，就完了。看下面的语句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了这里我相信很多人会和我一样，有崩溃感觉！vtype 做了索引了啊？怎么会慢呢？vtype做了索引是不错，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，从9万开始，那就是0.05*90=4.5秒的速度了。和测试结果8-9秒到了一个数量级。从这里开始有人提出了分表的思路，这个和discuz 论坛是一样的思路。思路如下：
建一个索引表： t (id,title,vtype) 并设置成定长，然后做分页，分页出结果再到 collect 里面去找info 。 是否可行呢？实验下就知道了。
10万条记录到 t(id,title,vtype) 里，数据表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。为什么会这样呢？我猜想是因为collect 数据太多，所以分页要跑很长的路。limit 完全和数据表的大小有关的。其实这样做还是全表扫描，只是因为数据量小，只有10万才快。OK，来个疯狂的实验，加到100万条，测试性能。
加了10倍的数据，马上t表就到了200多M，而且是定长。还是刚才的查询语句，时间是0.1-0.2秒完成！分表性能没问题？错！因为我们的limit还是9万，所以快。给个大的，90万开始
select id from t where vtype=1 order by id limit 900000,10; 看看结果，时间是1-2秒！
why 分表了时间还是这么长，非常之郁闷！有人说定长会提高limit的性能，开始我也以为，因为一条记录的长度是固定的，mysql 应该可以算出90万的位置才对啊？ 可是我们高估了mysql 的智能，他不是商务数据库，事实证明定长和非定长对limit影响不大？怪不得有人说 discuz到了100万条记录就会很慢，我相信这是真的，这个和数据库设计有关！
难道MySQL 无法突破100万的限制吗？？？到了100万的分页就真的到了极限？？？
答案是： NO !!!! 为什么突破不了100万是因为不会设计mysql造成的。下面介绍非分表法，来个疯狂的测试！一张表搞定100万记录，并且10G 数据库，如何快速分页！
好了，我们的测试又回到 collect表，开始测试结论是： 30万数据，用分表法可行，超过30万他的速度会慢道你无法忍受！当然如果用分表+我这种方法，那是绝对完美的。但是用了我这种方法后，不用分表也可以完美解决！
答案就是：复合索引！有一次设计mysql索引的时候，无意中发现索引名字可以任取，可以选择几个字段进来，这有什么用呢？开始的select id from collect order by id limit 90000,10; 这么快就是因为走了索引，可是如果加了where 就不走索引了。抱着试试看的想法加了 search(vtype,id) 这样的索引。然后测试
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再测试: select id ,title from collect where vtype=1 limit 90000,10; 非常遗憾，8-9秒，没走search索引！
再测试：search(id,vtype)，还是select id 这个语句，也非常遗憾，0.5秒。
综上：如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！
完美解决了分页问题了。可以快速返回id就有希望优化limit ， 按这样的逻辑，百万级的limit 应该在0.0x秒就可以分完。看来mysql 语句的优化和索引时非常重要的！
好了，回到原题，如何将上面的研究成功快速应用于开发呢？如果用复合查询，我的轻量级框架就没的用了。分页字符串还得自己写，那多麻烦？这里再看一个例子，思路就出来了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然对于in语句同样有效！看来网上说in无法用索引是错误的！
有了这个结论，就可以很简单的应用于轻量级框架了：
代码如下：
$db=dblink();
$db-pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db-execute($sql);
$strpage=$db-strpage(); //将分页字符串保存在临时变量，方便输出
while($rs=$db-fetch_array()){
$strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //构造出id字符串
$db-pagesize=0; //很关键，在不注销类的情况下，将分页清空，这样只需要用一次数据库连接，不需要再开；
$db-execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
php while($rs=$db-fetch_array()):
tr
td$amp;amp;$amp;nbsp; php echo $rs['id']; $amp;amp;$lt;/td
td$amp;amp;$amp;nbsp; php echo $rs['url']; $amp;amp;$lt;/td
td$amp;amp;$amp;nbsp; php echo $rs['sTime']; $amp;amp;$lt;/td
td$amp;amp;$amp;nbsp; php echo $rs['gTime']; $amp;amp;$lt;/td
td$amp;amp;$amp;nbsp; php echo $rs['vtype']; $amp;amp;$lt;/td
td$amp;amp;$amp;nbsp;a act=showid= php echo $rs['id']; $amp;quot;$ target="_blank"$amp;amp;$lt; php echo $rs['title']; $amp;amp;$lt;/a$amp;amp;$lt;/td
td$amp;amp;$amp;nbsp; php echo $rs['tag']; $amp;amp;$lt;/td
/tr
php endwhile;
/table
php
echo $strpage;
通过简单的变换，其实思路很简单：1）通过优化索引，找出id，并拼成 "123,90000,12000" 这样的字符串。2）第2次查询找出结果。
小小的索引+一点点的改动就使mysql 可以支持百万甚至千万级的高效分页！
通过这里的例子，我反思了一点：对于大型系统，PHP千万不能用框架，尤其是那种连sql语句都看不到的框架！因为开始对于我的轻量级框架都差点崩溃！只适合小型应用的快速开发，对于ERP,OA，大型网站，数据层包括逻辑层的东西都不能用框架。如果程序员失去了对sql语句的把控，那项目的风险将会成几何级数增加！尤其是用mysql 的时候，mysql 一定需要专业的dba 才可以发挥他的最佳性能。一个索引所造成的性能差别可能是上千倍！
PS: 经过实际测试，到了100万的数据，160万数据，15G表，190M索引，就算走索引，limit都得0.49秒。所以分页最好别让别人看到10万条以后的数据，要不然会很慢！就算用索引。经过这样的优化，mysql到了百万级分页是个极限！但有这样的成绩已经很不错，如果你是用sqlserver肯定卡死！而 160万的数据用 id in (str) 很快，基本还是0秒。如果这样，千万级的数据，mysql应该也很容易应付。
关于mysql处理百万级以上的数据时如何提高其查询速度的方法
最近一段时间由于工作需要，开始关注针对Mysql数据库的select查询语句的相关优化方法。
由于在参与的实际项目中发现当mysql表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。曾经测试对一个包含400多万条记录（有索引）的表执行一条条件查询，其查询时间竟然高达40几秒，相信这么高的查询延时，任何用户都会抓狂。因此如何提高sql语句查询效率，显得十分重要。以下是网上流传比较广泛的30种SQL查询语句优化方法：
1、应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。
2、对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
4、尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5、下面的查询也将导致全表扫描：(不能前置百分号)
select id from t where name like ‘%c%’
若要提高效率，可以考虑全文检索。
6、in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=’abc’–name以abc开头的id
select id from t where datediff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id
应改为:
select id from t where name like ‘abc%’
select id from t where createdate=’2005-11-30′ and createdate’2005-12-1′
10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使 用，并且应尽可能的让字段顺序与索引顺序相一致。
12、不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(…)
13、很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14、并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段 sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15、索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18、尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19、任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20、尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21、避免频繁创建和删除临时表，以减少系统表资源的消耗。
22、临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使 用导出表。
23、在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24、如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25、尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26、使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27、与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29、尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
30、尽量避免大事务操作，提高系统并发能力。
在用户点击一篇采购文章，会匹配到该文章全部相关内容。所有数据是存在ES中的，百万量级。恩~要用python写一个接口。通过查找资料，通过 ES模糊搜索 可以实现。
prefix的匹配一般是处理不分词的场景，将会匹配articleID中以”J”开头的doc。prefix不会计算revelance score，只是作一个过滤的操作，和filter唯一的区别是filter会缓存结果，而prefix不会。前缀越短要处理的doc越多，性能越差。
?会匹配任意字符，*会匹配0个或多个字符。性能根prefix一样差，必须要扫描整个倒排索引。
[0-9]：指定范围内的数字
[a-z]：指定范围内的字幕
.：一个字符
+：前面的正则表达式可以出现一次或多次
正则的搜索同样会扫描全表，性能也会很差
fuzziness参数调整纠正的次数
通常不会直接用上述搜索，而会用下面的搜索：
在es中，使用组合条件查询是其作为搜索引擎检索数据的一个强大之处，在前几篇中，简单演示了es的查询语法，但基本的增删改查功能并不能很好的满足复杂的查询场景，比如说我们期望像mysql那样做到拼接复杂的条件进行查询该如何做呢？es中有一种语法叫bool，通过在bool里面拼接es特定的语法可以做到大部分场景下复杂条件的拼接查询，也叫复合查询
首先简单介绍es中常用的组合查询用到的关键词，
filter:过滤，不参与打分
must:如果有多个条件，这些条件都必须满足 and与
should:如果有多个条件，满足一个或多个即可 or或
must_not:和must相反，必须都不满足条件才可以匹配到 ！非
发生 描述
must
该条款（查询）必须出现在匹配的文件，并将有助于得分。
filter
子句（查询）必须出现在匹配的文档中。然而不像 must查询的分数将被忽略。Filter子句在过滤器上下文中执行，这意味着评分被忽略，子句被考虑用于高速缓存。
should
子句（查询）应该出现在匹配的文档中。如果 bool查询位于查询上下文中并且具有mustor filter子句，则bool即使没有should查询匹配，文档也将匹配该查询 。在这种情况下，这些条款仅用于影响分数。如果bool查询是过滤器上下文 或者两者都不存在，must或者filter至少有一个should查询必须与文档相匹配才能与bool查询匹配。这种行为可以通过设置minimum_should_match参数来显式控制 。
must_not
子句（查询）不能出现在匹配的文档中。子句在过滤器上下文中执行，意味着评分被忽略，子句被考虑用于高速缓存。因为计分被忽略，0所有文件的分数被返回。
下面用实验演示一下上述查询的相关语法，
1、首先，我们创建一个索引，并且在索引里添加几条数据，方便后面使用，
我这里直接批量插入数据，也可以通过PUT的语法单条执行插入，
POST /forum/article/_bulk
{ "index": { "_id": 1 }}
{ "articleID" : "XHDK-A-1293-#fJ3", "userID" : 1, "hidden": false, "postDate": "2019-07-01","title":"java contains hadoop and spark","topic":"java" }
{ "index": { "_id": 2 }}
{ "articleID" : "KDKE-B-9947-#kL5", "userID" : 1, "hidden": false, "postDate": "2019-07-02",title":"php contains admin","topic":"java and php" }
{ "index": { "_id": 3 }}
{ "articleID" : "JODL-X-1937-#pV7", "userID" : 2, "hidden": false, "postDate": "2019-07-03" ,title":"spark is new language","topic":"spark may use java"}
{ "index": { "_id": 4 }}
{ "articleID" : "QQPX-R-3956-#aD8", "userID" : 2, "hidden": true, "postDate": "2019-07-04" ,title":"hadoop may involve java","topic":"big data used"}
或者使用put语法
PUT /forum/article/4
{
"articleID": "QQPX-R-3956-#aD8",
"userID": 2,
"hidden": true,
"postDate": "2019-07-04",
"title": "hadoop may involve java",
"topic": "big data used"
}
4条数据插入成功，
2、termQuery,term查询不分词，类似于mysql的where filedName = ? 语法，即精准匹配，比如我们查询articleID = XHDK-A-1293-#fJ3的这条数据，
GET /forum/article/_search
{
"query": {
"term": {
"articleID.keyword":"XHDK-A-1293-#fJ3"
}
}
}
2、must查询，即查询的条件中必须匹配的字段，例如，查询title中必须包含java的数据，
GET /forum/article/_search
{
"query": {
"bool": {
"must": [
{"term":{"title":"hadoop"}}
]
}
}
}
查出两条数据
如果是should呢？如下语法，即查询title中包含hadoop或者topic中包含spark，二者满足其一即可，
GET /forum/article/_search
{
"query": {
"bool": {
"should": [
{"term":{"title":"hadoop"}},
{"term": {"topic": "spark"}}
]
}
}
}
查询出3条数据，
must和should结合使用，
最后再来一个比较复杂的嵌套查询，我们先看一下这条sql语句，
select *
from forum.article
where article_id=‘XHDK-A-1293-#fJ3’
or (article_id=‘JODL-X-1937-#pV7’ and post_date=‘2017-01-01’)，
对应着转化为es的复合查询语法是怎样的呢？拆分来看，就是一个should语句的嵌套，
GET /forum/article/_search
{
"query": {
"bool": {
"should": [
{
"term": {
"articleID.keyword": "XHDK-A-1293-#fJ3"
}
},
{
"bool": {
"must": [
{
"term": {
"articleID.keyword":"JODL-X-1937-#pV7"
}
},
{
"term": {
"postDate":"2019-07-01"
}
}
]
}
}
}
}
查询到一条结果，按照这种思路，如果我们对一个复杂的查询不知道如何构建查询语句时，可以考虑先按照sql的语法进行拆分，然后再组织es查询语句是个不错的突破口，
到这里，可能我们会有疑问，复合条件中的term查询和单纯的match区别在哪里呢？既然都是查询，究竟原理有何不同呢？
我们知道match query是需要全文检索的，是进行full text的全文检索，当然如果搜索的字段值做了not_analyzed，match query也相当于是term query了，比如下面这个搜索，由于在插入数据的时候我们没有对title这个字段进行规定，默认就是text类型的，会被自动分词，这样查询的时候只要title中包含了 hadoop，就可以匹配到，
GET /forum/article/_search
{
"query": {
"match": {
"title": "hadoop"
}
}
}
2、有些情况下，假如我们直接使用match进行查询，又希望查出来的结果尽可能是我们期望的包含更多关键词的结果，则在match进行匹配的时候可以添加其他的条件，以便提升结果的匹配精确度，
GET /forum/article/_search
{
"query": {
"match": {
"title": {
"query": "java hadoop",
"operator": "and"
}
}
}
}
这样匹配出来的结果包含了更多我们期望的关键词，即query中可以指定我们查询的结果中包含的关键词，
es还有其他的语法达到上述的效果，minimum_should_match ，通过这个语法，可以指定匹配的百分数，就是查询的关键词至少要达到的百分数，下面这个表示全部匹配，只查询到一条结果，
假如我们将百分数调低点，比如75%，可以看到查到两条结果，
3、当然，我们也可以将bool和match结合起来使用，如下，
GET /forum/article/_search
{
"query": {
"bool": {
"must": [
{"match": {"title": "java"}}
],
"must_not": [
{ "match": { "title": "spark"}}
]
, "should": [
{
"match": {
"title": "php"
}
}
]
}
}
}
通过这种方式，也可以达到更精准的匹配我们期望的查询结果，
简单总结来说，当我们使用match进行查询的时候，如果查询的field包含多个词，比如像下面这个，
{
"match": { "title": "java elasticsearch"}
}
其实es会在底层自动将这个match query转换为bool的语法bool should，指定多个搜索词，同时使用term query，则转化后的语法如下，
{
"bool": {
"should": [
{ "term": { "title": "java" }},
{ "term": { "title": "elasticsearch" }}
]
}
}
而上面所说的match中加and的查询，对应于bool查询，转化后为 term+must 的语法如下，
{
"match": {
"title": {
"query": "java elasticsearch",
"operator": "and"
}
}
}
{
"bool": {
"must": [
{ "term": { "title": "java" }},
{ "term": { "title": "elasticsearch" }}
]
}
}
对于minimum_should_match这种语法来说，道理类似，
{
"match": {
"title": {
"query": "java elasticsearch hadoop spark",
"minimum_should_match": "75%"
}
}
}
{
"bool": {
"should": [
{ "term": { "title": "java" }},
{ "term": { "title": "elasticsearch" }},
{ "term": { "title": "hadoop" }},
{ "term": { "title": "spark" }}
],
"minimum_should_match": 3
}
}
我们来看一个具体的操作实例，也就是说必须至少包含3个关键词的数据才会出现在搜索结果中，
3、在搜索中，我们有这样一种需求，期望搜索的结果中包含java 如果标题中包含hadoop或spark就优先搜索出来,同时呢，如果一个帖子包含java hadoop，一个帖子包含java spark，包含hadoop的帖子要比spark优先搜索出来,
对于这样的需求，通俗来讲，就是需要通过增大某些搜索条件的权重，从而在搜索的结果中，更多符合和满足我们业务场景的数据靠前搜索出来，在es中可以通过boost关键词来增加搜索条件的权重，
GET /forum/article/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"title": "java"
}
}
],
"should": [
{
"match": {
"title": {
"query": "hadoop"
}
}
},
{
"match": {
"title": {
"query": "spark",
"boost":2
}
}
},
{
"match": {
"title": {
"query": "php"
}
}
},
{
"match": {
"title": {
"query": "hadoop",
"boost": 5
}
}
}
]
}
}
}
上面这个例子意思是我们赋予搜索的title中包含hadoop的条件权重更大，hadoop的结果会有限被搜索出来
4、dis_max语法，也叫best_field,在某些情况下，假如我们在bool查询中用多个字段进行查询，但是查询一样，就可能导致说查询出来的结果并不是按照我们期望的那个字段将其排在前面，也就是说，我们只需要包含指定字段的内容展示在前面，如下，
GET /forum/article/_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "java solution" }},
{ "match": { "content": "java solution" }}
]
}
}
}
title和content的搜索条件相同，但我们希望的是结果中title 包含java solution的靠前展示，但直接这样查询可能达不到预期的效果，如果使用dis_max进行拼接就可以了，
GET /forum/article/_search
{
"query": {
"dis_max": {
"queries": [
{ "match": { "title": "java solution" }},
{ "match": { "content": "java solution" }}
]
}
}
}
通过这样的方式，使得查询的结果更符合预期值，
5、但是使用dis_max，只取某一个query最大的分数，完全不考虑其他query的分数，即假如说某个结果中包title含了java，但topic中没有包含java，另一却是相反，还有的结果是两者都包含java，在dis_max语法下，只会拿到相关度得分最高的那一个，而不会考虑其他的结果，这时，如果需要获取其他的title或者topic包含java的结果，可以使用tie_breaker进一步包装，如下，
GET /forum/article/_search
{
"query": {
"dis_max": {
"queries": [
{ "match": { "title": "spark" }},
{ "match": { "topic": "java"}}
],
"tie_breaker": 0.6
}
}
}
这样查到3条结果，综合来说，最终还是需要结合实际业务场景进行使用，但是在大多数情况相爱，我们还是希望搜索的结果中是按照我们给定的条件包含更多的关键词的内容被优先搜索出来，
