Scan 搜索过程是如何保证单次扫描的响应延迟并减少资源消耗的？

Scan 搜索过程是分页、交互式的，这种设计有两个主要目的：一是保证了单次扫描的响应延迟，通过分页机制模拟了人们查看日志的习惯（类似于在命令行中使用 grep | head -n {number}），使得每次返回的数据量可控，从而保证了查询的响应速度；二是减少了不合理的查询语句消耗过多资源而产生费用浪费的情况，因为用户可以在看到初步结果后及时调整查询条件，避免进行大规模但可能不必要的扫描。

优化日志服务的查询效率可以通过以下方法：

增加Shard数量：确保平均每个Shard扫描的数据不多于5000万条，可通过分裂Shard增加计算资源，但会产生更多费用且只对新数据生效。
缩减查询范围：查询的时间范围越小，速度越快。尽量减少查询的数据量。
多次重复查询：不精确的查询可多次尝试，系统会利用已有的结果加速分析。
优化SQL语句：
避免基于字符串列的分组统计。
避免多列分组，特别是字典大的字段放后面。
使用估算函数而非精确统计。
仅选择需要的列，避免读取所有列。
非分组列放入聚合函数中。
避免使用IN语法，考虑用OR替代。
详情可参考优化查询文档。