AliSQL 8.0.44-2 — 五大核心能力
AliSQL 8.0.44-2 在 8.0.44-1 的 DuckDB HTAP 首发基础上继续扩展：升级 DuckDB 集成，并加入原生向量检索、Native Flashback、Binlog in Redo V2 与 Binlog Cache Free Flush。
五大核心能力
五条能力路径各有清晰边界：DuckDB 承载分析，Vector Index 与 Native Flashback 位于 InnoDB 路径，两项 Binlog 机制分别优化符合条件的事务提交。
将 DuckDB 深度集成为 AliSQL 的分析存储引擎，在保持 MySQL 协议和 SQL 接口的同时提供列式存储与向量化执行。支持 InnoDB 联机事务处理（OLTP）主库与 DuckDB 分析副本，通过 Row-based Binlog 持续同步数据。8.0.44-2 将 DuckDB 升级到 1.4.4，增强 SQL 兼容性、数据定义语言（DDL）、复制可靠性，以及查询和复制线程的 CPU（中央处理器）资源治理。
02 · Native Vector SearchVector Search, Native to MySQL在 InnoDB 中原生提供 VECTOR(N) 数据类型和分层可导航小世界（HNSW）近似最近邻（ANN）索引，支持欧氏距离与余弦距离。向量检索可直接与普通 SQL 条件组合，无需部署独立向量数据库，适用于语义搜索、检索增强生成（RAG）和推荐等场景；最高支持 16,383 维向量，并包含单指令多数据（SIMD）等执行优化。
03 · Native FlashbackQuery Your Data in the Past通过 AS OF TIMESTAMP 直接查询历史数据。AliSQL 周期性保存 InnoDB Snapshot 并保留所需 Undo，通过多版本并发控制（MVCC）重建指定历史时间点的一致性 Read View。发生误删或误更新时，可直接查询历史版本，无需先恢复备份再重放 Binlog。
04 · Binlog in Redo V2Faster Commit with Redo-Backed Binlog将符合条件的 Binlog Event 写入 InnoDB Redo 的持久化边界，由后台线程异步写入并同步 Binlog，减少前台事务提交路径上的 Binlog 输入输出（I/O）。发生崩溃时，如果 Binlog 尾部落后于已持久化 Redo，可从 Redo 自动重建缺失的 Binlog。
05 · Binlog Cache Free FlushLarge Transactions Without Double Write针对符合条件的大型 InnoDB 事务优化 Binlog Commit。传统路径需要把已经溢写到磁盘的 Binlog Cache 再完整复制到 Binlog；Free Flush 通过预留 Header 并将临时文件直接转换为新的 Binlog 文件，避免第二次大规模数据复制，降低 I/O 与长时间持锁带来的实例抖动。
默认值
大多数新功能默认关闭。Flashback 查询开关已开启，但快照生成和 Undo 保留仍未开启。
| 领域 | 功能 | 开源默认值 |
|---|---|---|
| 分析 | DuckDB 存储引擎 | duckdb_mode=NONE |
| 向量检索 | VECTOR 类型和 HNSW 索引 | vidx_disabled=ON |
| 大事务 | Binlog Cache Free Flush | OFF |
| Binlog 持久性 | Persist Binlog Into Redo V2 | persist_binlog_to_redo=OFF |
| 历史查询 | Native Flashback | 快照任务 OFF；Undo 保留时间 0 |
每项功能都有各自的启动条件、事务要求、拓扑限制或 SQL 兼容性限制。请按计划使用的功能组合进行验证；不满足 Binlog 优化条件的事务会使用标准 Binlog Group Commit。