数据库的发展，从来不只是软件工程的一段分支史。
数据库更像是一部现代社会组织知识、沉淀规则、压缩复杂性的基础设施史。工业时代把动力写进机器，信息时代把逻辑写进程序，而数智时代正在推动我们把越来越多的数据处理秩序，写入更接近物理层的系统结构之中。
回望过去，数据库已经走过几个清晰阶段：从依赖规则的经验式优化，到基于统计信息与代价模型的理性优化，再到引入机器学习与运行时反馈的自适应优化。执行计划始终位于这条演进主线的中心——它决定数据如何被扫描、过滤、连接、排序、聚合，也决定延迟、吞吐、能耗与资源占用的上限。
向前看，一个更深的变化正在出现：执行计划正在从“软件中的指令组织”，逐步走向“硬件中的物理实现”。
这不是单纯的加速，而是一次范式转向——数据库不再只是运行在通用硬件上的复杂软件，而开始通过软硬协同，把核心的数据处理路径固化为更高效、更稳定、更节制的计算结构。
一、真正的问题，不只是“选得对不对”，而是“跑得像不像数据库”
传统执行计划的核心任务，是在多条候选路径里挑出相对更优的物理方案：是否用索引、选什么连接顺序、哈希还是嵌套循环、是否下推过滤、何时排序聚合。这套机制在过去几十年极大推动了数据库发展。
但今天的主要矛盾，已经不再只是优化器“选错计划”，而是数据库工作负载与通用硬件之间存在天然失配。
数据库的核心算子普遍具有强结构化特征：扫描是连续的数据流读取，过滤是规则明确的条件判定，连接是对键空间的映射、探测与归并，排序是受限内存下的比较与重排，聚合是状态累积与分组压缩，压缩、解压、加密、校验则是随数据流动反复出现的路径操作。它们高度重复、数据流强、局部性强、并行性强。
问题在于，大多数数据库仍要把这些结构化负载塞进通用 CPU 的执行框架：经过执行引擎、函数调用、线程调度、缓存搬运、内存复制与层层抽象之后，数据库在“逻辑上”完成了查询，却在“物理上”付出了极高代价。
因此，下一步不应只是在优化器里再堆规则、特征或模型，而应重新回答一个更根本的问题：既然执行计划本质上是在组织数据流，其中稳定、频繁、重负载的部分，就应当被直接组织为硬件。
二、执行计划硬件化，是一条由浅入深的技术路径
“执行计划成为硬件”容易被误解为“数据库将变成一块芯片”。实际上，它不是一步到位的替代，而是一条渐进演进路线。
第一层：计划即专用指令。 现实的起点不是做 ASIC，而是让执行计划摆脱软件执行器的重度解释，下沉为更适合硬件消费的中间表示——优化器输出的不应只是供通用执行器调用的 plan tree，还应进一步下沉为稳定的算子 IR 或数据库专用指令。Scan 成为数据流读取原语，Filter 成为谓词判定单元，Projection 成为列裁剪与求值单元，Hash Build/Probe 成为键值映射结构，Sort/Aggregate 成为有明确状态模型的处理模块，Compress/Encrypt/Checksum 成为数据路径中的伴生能力。
这一步让数据库第一次把“执行计划”转化为可被软硬协同消费的结构化描述——数据库开始拥有自己的“硬件友好语言”。
第二层：计划即数据通路。 再进一步，是把高频核心算子映射为硬件流水线或可重构数据通路，适合从列扫描与谓词过滤、压缩/解压与加解密、Hash Join 的局部 build/probe、Group By 与常用聚合、排序/TopN/字符串匹配、数据同步与日志传输的校验链路开始。
这些能力一旦进入 FPGA、DPU 或专用加速模块，就从“CPU 在跑一个数据库算法”变成“硬件在承载一条数据库通路”。
此时合理的设计不是让硬件接管一切，而是重新分层：控制面仍由 CPU 与数据库内核承担（事务管理、计划生成、调度编排、并发控制与恢复），数据面逐步交给 DPU/FPGA/ASIC（高频、规则稳定、吞吐密集的算子）。
第三层：计划即运行时智能。 更远的方向，是在软硬协同之上引入 AI 与运行时反馈，让执行计划从“静态编译”走向“动态编排”。大模型与智能体的价值不在于替数据库执行 SQL，而在于担任元优化层：学习长期 workload 分布、识别稳定热点模板、预测数据倾斜与缓存失配、决策哪些算子值得固化、做参数调优与算子 placement、在复杂场景下触发快慢路径切换。
到了这一步，优化不再是一次性搜索，而成为一套持续感知、校正与重构的基础设施能力。
这一方向也正与更宏观的计算趋势合流：DPU/SmartNIC 正逐步成为云基础设施的重要卸载层，CXL 让内存池化与近存计算成为可能，而以 Velox、DuckDB 为代表的向量化执行引擎和以 RAPIDS 为代表的 GPU 分析栈，正在分析侧重新定义数据通路的组织方式。
三、真正的难点，不在加速单个算子，而在守住系统语义
数据库硬件化容易犯的错，是只盯单个算法的加速，却忽视数据库是一个完整的秩序系统，而非若干算法的拼装体。
MVCC 可见性不是简单过滤条件。 对事务型数据库而言，难下沉的往往不是扫描本身，而是“这条记录当前事务是否可见”的语义判断——它牵涉事务快照、提交/回滚状态、版本链、vacuum 进度等一整套 MVCC 机制。硬件若不能理解这种语义，就只能做旁路，进不了核心事务主路径。
WAL、提交顺序与崩溃恢复不能被绕过。 数据库不仅要“算出结果”，还要对“崩溃后结果仍成立”负责。任何硬件化设计都必须回答：日志顺序如何对齐、提交点如何确认、缓冲状态如何持久化、崩溃恢复后硬件状态如何被软件重新解释。只谈性能、不谈恢复，进不了生产级核心。
数据分布变化会持续挑战硬件快路径。 一个 join 在均匀分布下表现良好，遇到热点键却可能突然退化；一个 group by 在低基数下可流式处理，高基数下却迅速膨胀；一个过滤条件今天高选择率，下一周可能完全相反。
因此成熟的设计必须守住两条原则：硬件快路径优先，但软件保底路径必须始终保留；运行时反馈必须能驱动快速回退与重编排。
真正好的系统，不是永远走快的路，而是始终知道什么时候该回到稳的路。
四、现实的落地路线
执行计划硬件化忌“大而全”，真正可落地的路线应当是分阶段、可验证、可回退的。
先行案例：这条路并不新，但今天才真正可行。 上世纪 80 年代曾出现过一批“数据库机器”（Britton-Lee、Teradata DBC/1012、Wisconsin 的 Gamma 等），试图用专用硬件处理数据库负载，却被通用微处理器性能的持续跃升所取代。今天条件已然不同——单核性能红利见顶、能耗与内存墙凸显，FPGA 的可重构性、DPU/ASIC 的专用化与云上负载的规模化，让软硬协同重新具备了经济性与灵活性。
近年的产业实践已经把这条路走通了第一段：
其共同点在于：都从“扫描—过滤—压缩—加密—聚合”这类高吞吐、低语义风险的路径切入，而非一步到位把数据库塞进芯片。这正是该被复制的那一步。
第一阶段：先完成内核内部的“准硬件化整理”。 接入任何硬件之前，内核自身要先整理出可下沉的边界——统一算子抽象、建立稳定算子 IR、推进向量化与批处理、完成表达式编译与算子融合、区分控制面与数据面接口、为热点路径建立可卸载边界。这仍是软件工作，却决定了未来能否走向芯片协同；没有统一 IR 与清晰边界，硬件化终只会变成零散 patch。
第二阶段：优先做高收益、低语义风险的卸载。 第一批适合放上 FPGA、DPU 或加速卡的能力，应满足三个条件：吞吐占比高、算法模式稳定、回退到软件也不破坏事务语义。现实起点通常是列式扫描与谓词过滤、压缩/解压/加解密、Hash Join 局部 build/probe、数据复制与日志传输中的校验搬运。这一步的关键不是“所有场景都快”，而是以有限代价显著降低 CPU 占用与尾延迟、提升能效比。
第三阶段：从“外挂能力”走向“体系能力”。 当数据库已具备稳定 IR、运行时反馈、快慢路径切换与软硬件接口后，才有资格做更深的重构——从 PCIe 卡走向 SoC/专用 DPU，从局部算子卸载走向整段查询通路编排，从单点优化走向事务、一致性、安全与加速的一体设计，从分析型旁路走向混合负载协同处理。
到这一阶段，竞争力不再只是“功能全不全、兼容广不广”，而是“能否把数据处理的核心秩序写进更低层的体系结构”。
五、下一阶段的竞争，不只是兼容，而是执行体系
过去一个时期，国产数据库的主要任务，是补齐兼容性、稳定性、生态适配与工程能力。未来决定下一轮竞争格局的，未必只是 SQL 兼容度与功能覆盖率，而是谁能更早完成执行体系层面的重构准备：
是否具备统一的算子抽象与 IR；
是否完成向量化、代码生成、并行调度与资源编排的统一框架；
是否为 FPGA、GPU、DPU 等异构设备预留稳定接口；
是否能够在硬件快路径与软件保底路径之间动态切换；
是否把事务、一致性、日志恢复与加速路径作为整体设计。
执行引擎现代化和软硬协同，进一步把存储、计算、状态与通信能力拆解成更轻量、更标准化的基础模块。其意义可能比“数据库加速”更深。
如果执行计划中的核心能力能够不断被标准化、硬件化和微型化，未来数据库未必只能以大型服务器软件的形态存在。它可能逐步演化为一种嵌入设备、边缘和网络中的有状态计算单元——Data Cell：每个节点拥有局部状态、局部计算、事件感知和邻域通信能力，而不需要理解整个系统。当这类单元进一步扩展到百万、千万甚至更大规模时，传统 Cluster 的中心化组织方式也可能发生变化。系统不再要求全局同步和全局视图，而更接近：局部自治、分层组织、状态传播、整体收敛。
这与生物系统存在一个值得关注的相似点：复杂能力并不一定来自一个更强的中央处理器，也可能来自大量简单单元在局部规则下长期协同形成的整体行为。因此，数据库与类生物智能真正可能发生联系的，并不是“节点数量达到多少”，而是存储、计算、通信与学习是否能够重新结合，并形成可持续自组织的体系结构。
结语
数据库的发展，表面是执行效率的演进，深处是计算秩序的演进。从规则驱动到代价驱动，从代价驱动到学习与反馈驱动，再从软件优化走向软硬协同，执行计划始终位于这条主线的中心。
当执行计划不再只是软件中的树，而开始成为数据通路、专用指令甚至硬件能力时，数据库也就不再只是“运行在机器上的软件”，而开始参与定义机器本身。
如果这些能力能够被微型化、复制和重新组织，数据库甚至可能从“大型系统”进一步演化为遍布数字世界的有状态计算单元。执行计划硬件化因此真正值得期待的，不只是更快的查询，而是一条更深的演进路径：被解释 —> 被成形，—> 被复制 —> 被组织。
数据库的未来，也许不只是更好地管理数据，而是逐渐成为组织计算秩序的基础设施。