我在GridDB Cloud实例上遇到TQL（GridDB的查询语言）性能方面的瓶颈。我的TimeSeries容器规模相当大（大约5 亿条传感器数据行），虽然简单的时间范围查询速度极快，但我更复杂的TQL语句现在开始明显变慢。

具体来说，我正在尝试运行一个同时按时间范围和非索引字符串列（如status_code或 device_type）过滤的查询。我注意到，一旦增加字符串过滤条件，查询时间就从亚秒级跃升至好几秒，这严重影响我的仪表板的响应速度。

Here's a snippet of the Python code I'm using to execute the query:

import griddb_python as griddb
import datetime


# This query is fast (uses the row key/timestamp index)
fast_tql = "SELECT * WHERE timestamp > TIMESTAMP('2026-07-01T00:00:00Z') AND timestamp < TIMESTAMP('2026-07-02T00:00:00Z')"

# This query is slow (adding a non-indexed string filter)
slow_tql = "SELECT * WHERE timestamp > TIMESTAMP('2026-07-01T00:00:00Z') AND timestamp < TIMESTAMP('2026-07-02T00:00:00Z') AND status = 'ERROR'"

try:
    query = container.query(slow_tql)
    row_set = query.fetch()

    while row_set.has_next():
        row = row_set.next()
        # Process data...
    print("Query completed.")
except Exception as e:
    print(f"Query failed: {e}")

我的核心问题是： 在GridDB Cloud上，当你需要在大型数据集上按多项条件进行过滤时，优化TQL查询的最佳实践是什么？具体包括：

1. 有没有办法“提示”查询优化器在扫描其他列之前优先使用时间戳索引？
2. 在GridDB Cloud中，在容器已经非常庞大（数百万行）后再为字符串列添加索引，会带来显著的开销或锁定吗？
3. 是否存在专门用于TQL的函数或结构（如TIME_NEXT或 TIME_PREV），在这类“带过滤条件的”时序查询中更高效？

我已经尝试通过SQL（CREATE INDEX）添加一个基础索引，但我担心对吞吐的影响，因为这个容器仍在以高速度写入。若有对大规模GridDB部署有经验的人给出意见，将是巨大的帮助！

解决方案

你显然需要在时间戳上设一个索引，因为这会加速此类基于时间戳的查询，就像第一种查询一样。第二种查询变慢的原因是在该时间区间内有大量匹配的记录，并且由于没有对其状态（status）进行索引，需要逐一对它们的状态进行评估。

一个解决方案是删除在 timestamp 上的一维索引，并在（timestamp, status）上创建一个复合索引：

create index idx_entity_timestamp_status on entity(timestamp, status)

这将保留你以前在 timestamp 上的索引带来的所有好处，同时在 status 上再增加一层内部索引，这样一旦找到你需要的所有时间戳，关于状态的其他可能检查将再次执行，应该会很快。