sql数据库无显式执行上下文与算子状态抽象，但隐含支持事务、窗口函数等所需状态；其状态为查询粒度、瞬态、无故障恢复设计，生命周期限于单次查询执行。
SQL数据库本身不直接提供“执行上下文”或“算子状态管理”的显式抽象——这些概念主要出现在流处理引擎（如flink、spark streaming）或自定义查询执行器中。但在关系型数据库（如postgresql、SQL Server、mysql）的查询执行层面，确实存在隐式的执行上下文和状态机制，用于支撑事务、窗口函数、游标、递归CTE、聚合中间结果等行为。
执行上下文：数据库内部的“查询快照”
执行上下文可理解为一条sql语句在运行时所需的全部环境信息，包括：
- 事务上下文：隔离级别、事务ID、回滚段位置（影响可见性判断，如MVCC中的snapshot xmin/xmax）
- 会话变量与设置：time zone、search_path、statement_timeout、enable_hashjoin等GUC参数（PostgreSQL）或session options（SQL Server）
- 绑定参数与常量折叠结果：预编译阶段确定的参数值、表达式简化结果（如 WHERE id = ? 被代入后触发索引选择）
- 游标/分页状态：DECLARE CURSOR 后维护的fetch位置、FETCH NEXT 的偏移跟踪
算子状态：物理执行计划中的中间态留存
数据库优化器生成的执行计划由多个物理算子（Scan、HashJoin、sort、Aggregate、windowAgg等）组成。其中部分算子需维持运行时状态：
- HashJoin 算子：构建侧（Build side）将数据哈希到内存/磁盘哈希表；探测侧（Probe side）逐行匹配——哈希表本身即为该算子的核心状态
- Stream Aggregate / Grouping Sets：按 group key 累计 sum/count/min/max，每个分组键对应一个内存中的聚合槽（slot），可能溢出到临时文件
- Window function（如 ROW_NUMBER(), AVG() OVER (…)）：需缓存当前窗口范围内的所有行（frame clause 决定大小），状态随滑动窗口动态增删
- Recursive CTE 执行器：维护“工作表”（working table）与“临时结果集”，迭代轮次间传递中间结果，本质是带版本的状态堆栈
如何观察与干预这类状态？
多数状态对用户透明，但可通过以下方式间接查看或影响其行为：
- 使用 EXPLaiN (ANALYZE, BUFFERS) 查看实际内存/磁盘使用、重散列次数、临时文件数量，推断状态规模
- 调整 work_mem（PostgreSQL）或 sort_buffer_size（MySQL）控制算子内存上限，避免状态溢出导致性能陡降
- 用 pg_stat_progress_* 视图（如 pg_stat_progress_hash_join）监控长时算子的内部状态进度
- 对窗口函数显式指定 ROWS BETWEEN … AND … 限制帧大小，防止无界状态累积
与流处理“状态管理”的关键区别
数据库的算子状态是瞬态、查询粒度、无故障恢复设计的：
- 状态生命周期=单条查询执行期，查询结束即释放（除临时表外）
- 不提供 checkpoint / savepoint 机制保存跨查询状态（物化视图、临时表、函数内变量属例外）
- 不支持状态后端切换（RocksDB / Memory / FS），所有状态由存储引擎统一管理
- 事务一致性由WAL+MVCC保障，而非靠状态回滚日志