请在 kibana 控制台中解释从 sql 进行查询转换的逻辑。最令人困惑的是"订单"："asc"，而我请求 desc。
数字"10985"和"11030"看起来也很奇怪。如果我重新运行翻译，这些数字正在发生变化。
我做一个查询翻译：
POST _sql/translate
{
"query": "SELECT day_of_week, avg(taxful_total_price) FROM kibana_sample_data_ecommerce WHERE customer_id = 52 GROUP BY day_of_week ORDER BY avg(taxful_total_price) DESC LIMIT 2"
}
译本：
{
"size" : 0,
"query" : {
"term" : {
"customer_id" : {
"value" : 52,
"boost" : 1.0
}
}
},
"_source" : false,
"stored_fields" : "_none_",
"aggregations" : {
"groupby" : {
"composite" : {
"size" : 1000,
"sources" : [
{
"10985" : {
"terms" : {
"field" : "day_of_week",
"missing_bucket" : true,
"order" : "asc"
}
}
}
]
},
"aggregations" : {
"11030" : {
"avg" : {
"field" : "taxful_total_price"
}
}
}
}
}
}
关于变化的数字，它们只是聚合的名称;就好像你会在sql中使用"AS 11030"一样。它允许您通过重新命名来在其他聚合中使用聚合。必须在 ES 查询的结构中具有聚合的名称。也许用数字随机命名聚合是翻译的正常行为。它不应对查询结果或其行为产生影响。
聚合名称没有意义，它们是随机生成的，但 ES-SQL 会跟踪哪个是哪个(显然(，每当一个聚合需要另一个聚合的结果时，它就知道要使用哪个。
有一个改进请求 - https://github.com/elastic/elasticsearch/issues/43531 - 具有一致的命名，以便可以使用缓存。尚未实施，目前不在近期路线图上。
关于ascDESC 差异，如果你仔细观察，你的DESC排序是AVG而asc排序是针对composite的terms聚合，这是两回事。ES-SQL 在聚合"客户端"端(与服务器/ES 端相反(执行排序，因为没有 ES 查询在使用聚合时执行该排序composite。
最重要的是，你在那里看到的查询是完整的，但不完全是，因为这是ES-SQL在Elasticsearch上运行的查询，但还有一个客户端任务通过AVG执行实际排序。已经打开了一个改进问题来增强translateAPI，以表明至少生成的查询可能不足以获得与用户在 ES 本身上运行该查询时相同的结果。