Excel add-in开发中能否对工作表表格执行SQL查询或基于Excel建库取数

能否直接对工作表内的原生表格执行SQL查询 #

不存在无需中间转换的直接原生查询能力。
Excel本身的数据引擎并非关系型数据库，无法在add-in运行环境下，直接把工作表上的结构化表格（ListObject）映射为SQL解析器可直接识别的关系型表结构。即使是传统的ADO/ODBC连接Excel的方式，本质也是通过驱动层读取磁盘上的静态Excel文件内容，并非直接读取内存中当前打开的工作表实时数据——如果用户修改了单元格内容但未保存文件，这类连接方式根本无法获取到最新值，和“直接查询工作表内表格”的预期有本质差异。
针对你提到的包含Height、Width两列的示例表格，如果不做任何中间处理直接传入SQL语句，SQL引擎根本无法识别表名映射、字段位置、数据行范围这些核心关联关系，无法返回正确结果。

基于工作表数据构建临时数据库执行SQL的可行性 #

这种方案完全可落地，也是当前Excel add-in场景下体验最优的实现路径，全程无磁盘IO、无需落盘生成数据库文件：

• 第一步通过Office.js/VSTO提供的API，读取工作表内目标结构化表格的内存数据：提取表头字段列表、逐行读取单元格值，整理成结构化的数据集
• 第二步将数据集注入到进程内嵌入的轻量SQL引擎中，在引擎内部把这份内存数据映射为一张临时关系表，不需要启动独立的数据库服务
• 第三步即可直接执行你提到的select height from table where width = 5这类自定义SQL语句，引擎会完成条件匹配、字段筛选，直接返回对应查询结果
  对比传统的ODBC连接Excel文件的方案，这种实现完全读取工作表的实时内存数据，不需要强制用户先保存文件，也不会出现文件被占用、磁盘权限不足导致的连接失败问题。

实际开发中的常见注意事项 #

• 不要将传统ODBC/ADO连接Excel文件的方案等同于直接查询工作表：这类方案读取的是磁盘上的静态快照数据，容易出现新旧数据不一致、文件锁冲突导致的Excel崩溃问题
• 做好单元格的数据类型映射：Excel的单元格本身没有强类型属性，需要根据字段定义把数字、文本、空值转换为SQL引擎可识别的对应类型，否则会出现where width =5这类条件因为类型不匹配无法命中结果的问题
• 对超大规模的表格数据做流式加载处理：不要一次性将数十万行数据全量塞入内存SQL引擎，避免add-in出现内存溢出、运行卡顿的问题

内容的提问来源于stack exchange，提问作者Nimz