先交代下我们的使用场景。我们是把一张分库分表的逻辑表导入了 OpenSearch，建立了相关索引，供后台管理界面查询使用。最近在使用的过程中遇到了几个问题。记之。
查询的数据最多只有 5000 条
我们有一个数据导出功能，当导出的数据超过 5000 条时，导出的表格里就只有 5000 条。我们使用的是 search 接口分页查，看日志发现当 startHit 到 5000 左右就返回失败了。咨询了下得知 search 接口为了保证能及时返回，当 startHit + hit > 5000 时就返回失败了。如果需要获取全量的数据需要用 scroll 接口。V3 可以参照这个来写，scroll迭代查询Demo，V2 的文档不太完善，试了几次才试出来。。。
query 子句长度不能超过 1k
我们的查询页面需要按照多个维度来查询，比如日期，发货仓，到货地等，而且都是多选，当日期跨度范围比较大的时候，query 子句的日期部分是这样的：
timekey: "2017-06-01" OR timekey: "2017-06-02” OR timekey: "2017-06-03” ...当日期跨度比较大的时候发现查询又失败了。咨询了下 Hooch，query 子句编码后长度不能超过 1k，filter 子句长度不能超过 4k。然后教了我一种简洁的写法。
timekey:"2017-06-01"|"2017-06-02"|"2017-06-03” ...然而只是这样还是不够，日期只是我的查询条件之一，几个条件加起来很容易超过 1k。比如到货地，当按照某个行政级别（比如省）查询时，需要把该级别和该级别下面各级别的数据都筛选出来，如果也这样遍历的话很容易就超了。想过把部分条件放到 fitler 子句里，但是 fitler 子句只支持 “> <“ 这样的过滤条件。另外想到的就是分多次查，但是分多次多个查询条件怎么拆分，还有怎么做分页，想想就觉得很痛苦。
继续翻文档的过程中，发现 OpenSearch 支持 “^31” 这样的语法来查 31 开头的数据（字段类型需是 SHORT_TEXT，分词模式选模糊分词），而地址 id 下级地址和上级地址的前缀又是一样的，通过这种方式很容易匹配一个行政级别下面的数据。同样的思路，其他字段的查询语句超长时，我也可以通过求公共前缀的方式来压缩长度。
为什么在使用 MySQL 的时候没遇到过 sql 过长的问题
联想了一下，对语句长度做限制应该是普遍存在的，为什么在之前使用 MySQL 批量插入的时候没遇到过类似问题。查了下，MySQL server 的max_allowed_packet 参数是限制接收到的包体长度的，默认值是 1M。
查询有 doc 丢失
运营同学在使用过程中发现有时会丢失一些数据。继续咨询，得到的回复是这样的
引擎更新文档是一整篇更新，更新流程是 先 delete 再 add。所以会有一瞬间找不到文档
这个问题目前没有解决方法，记录更新得越频繁就越容易出现这种情况。对于“频繁”没有具体的参数值，但是一秒钟有几次更新的话会被认为频繁。
最后，感谢 @Hooch 和 @本岩的答疑。
