正文
由于 VIDEX 将真实数据库实例、虚拟数据库实例、算法服务器三个部分解耦了，因此可以灵活应用于各种适用场景，从个人研究到生产环境部署：
作为插件安装到真实数据库
：将 VIDEX 作为插件安装到真实数据库实例，这样只需要一台 MySQL实例，即可体验基于虚拟索引的各种 what-if 分析。适合于个人实验和分析。
以独立实例启动
：独立启动 VIDEX 示例，同步统计信息，然后开始分析。此模式可以完全避免影响在线运行实例的稳定性，在工业环境中很实用。
与 VIDEX-Optimizer 配套启动
：最经典的方式，无须额外设置，VIDEX-Optimizer 会自动寻找本地启动的VIDEX算法服务器。
独立启动算法服务器
：只要设置一下 SQL 环境变量（
SET @
VIDEX_STATISTIC_SERVER
='ip:port'
），VIDEX-Optimizer 会将算法请求转发到指定的算法服务器上。对于研究者来说，可以自由实现算法、启动自定义的算法服务；对于云原生场景，可以将大量 MySQL 实例的算法请求发往中心式的算法服务，便于运维和快速更新。
非任务模式：
默认情况下，用户不需要关注 “task_id” —— 只需要指定目标库、指定虚拟库，同步数据即可；
任务模式：
在大规模分析任务中（例如大规模索引推荐任务），各种用户往往会对同一个生产库的不同表、或不同实例的同名表发起多次分析。这种情况下，用户可以指定任务 id（
SET @VIDEX_OPTIONS={'task_id': 'abc'}
），让多个任务彼此互不影响。
MySQL 采用了分离式的架构，上层的查询优化器会向下层存储引擎请求各种信息，包括元数据信息（table_rows、data_length 等等）、独立值（ndv）、基数（cardinality）、索引内存加载率等等。其中基数估计和独立值估计是 AI for DB 研究领域的热点方向。现已有大量 data-driven 或者 query-driven 的算法被提出，但这些算法往往只能以 PostgreSQL 作为试验场。
VIDEX 让用户不必与 MySQL 查询优化器做交互、也屏蔽了 MySQL 对库表元数据信息（table_rows、deta_length）的请求。由此，用户可以专注于一些重点的算法问题，例如 NDV 估计和 Cardinality 估计。
方法 1：在 VIDEX-Statistic-Server 中添加一种新方法
考虑到许多研究者习惯于用 Python 研究各种 AI 与 DB 结合的算法，因此，我们用Python 实现了 VIDEX-Statistic。
用户可以继承并修改
VidexModelInnoDB
。
VidexModelInnoDB
为用户屏蔽了系统变量、索引元数据格式等复杂细节，并提供了一个基于独立、均匀分布假设的 ndv 和 cardinality 算法。这样用户可以聚焦于 cardinality 和 ndv 这两个研究热点：
class VidexModelBase(ABC): """ Abstract cost model class. VIDEX-Statistic-Server receives requests from VIDEX-Optimizer for Cardinality and NDV estimates, parses them into structured data for ease use of developers. Implement these methods to inject Cardinality and NDV algorithms into MySQL. """ @abstractmethod def cardinality(self, idx_range_cond: IndexRangeCond) -> int: """ Estimates the cardinality (number of rows matching a criteria) for a given index range condition. Parameters: idx_range_cond (IndexRangeCond): Condition object representing the index range. Returns: int: Estimated number of rows that match the condition.
