发布 2 介绍 动态 20 社区 2

MySQL AI UI

MySQL AI UI 是一个面向 MySQL 场景的本地桌面数据分析工具。它把传统数据库客户端、自然语言转 SQL、轻量看板、参数化查询和交付分享能力放在同一个应用里，让团队可以直接连接自己的 MySQL 数据库，在本地完成查询、分析、沉淀和交付，而不是把数据搬到外部 SaaS。

这个项目特别适合“没有完整 BI 团队，但又需要把业务数据快速用起来”的团队：技术同学可以先配置连接、模型、指标和模板，产品、运营、业务负责人再基于这些能力做日常分析和看板查看。

这个项目是做什么的

它解决的是一个很常见的问题：

  • 团队已经有 MySQL 数据，但日常分析还依赖研发临时写 SQL
  • 业务同学会提问题，但不会写 SQL 或不熟悉表结构
  • 现成 BI 平台太重、太贵，或者引入成本太高
  • 团队又不希望把核心业务数据上传到第三方平台

MySQL AI UI 的思路不是替代数据库，也不是做一个云端大而全平台，而是提供一个本地运行的智能分析客户端：

  • 像普通 MySQL 客户端一样直连数据库
  • 读取 schema，帮助 AI 理解库表结构
  • 把自然语言问题转换为 SQL
  • 对 SQL 做只读安全校验后执行
  • 将结果保存为指标卡、图表或表格
  • 进一步组织成业务看板
  • 还可以把连接、AI 配置和看板能力打包分享给其他团队或客户环境

核心定位

从产品形态上看，它是一个“本地客户端 + AI 辅助查询 + 轻量 BI 看板”的组合。

从使用方式上看，它更像一个适合中小团队、实施交付、内部模板复用的工具，而不是一个复杂的企业级数据中台。

从数据安全上看，它强调“数据尽量不出域”：

  • 应用本地运行
  • 直接连接 MySQL
  • 本地保存连接、AI 配置和应用状态
  • 支持使用本地 Ollama 模型，进一步减少外部依赖

从权限控制上看，它尽量复用企业已经存在的 MySQL 原生账号体系，而不是在应用侧再发明一套独立权限模型。这样做的好处是：权限边界更清晰，审计责任更明确，也更容易接入现有 DBA 管理流程。

适合谁用

  • 产品经理、运营、业务负责人：用自然语言提问、看固定看板、做经营复盘
  • 数据或研发同学：维护连接、确认口径、沉淀标准 SQL 和参数模板
  • 实施顾问或交付团队：把一套分析模板打包后交付给不同客户环境
  • 小团队创业项目：先用一个本地工具快速把分析体系跑起来

主要能力

1. MySQL 连接管理

  • 保存数据库连接信息
  • 支持环境标识、标签、描述
  • 支持 SSH 跳板机场景
  • 推荐按业务线或环境维护多个连接

连接信息和应用状态会保存到用户本地目录中。当前代码里默认路径来自 os.UserConfigDir()，例如在 macOS 上通常位于：

~/Library/Application Support/mysql-ai-ui

其中会包含本地 SQLite 状态库，例如 connections.db。

2. AI 配置与多 Provider 支持

当前内置支持以下 AI Provider：

  • Kimi
  • DeepSeek
  • Ollama

这意味着项目既可以接在线模型，也可以接本地模型。对于重视数据出域控制的场景，可以优先使用本地 Ollama；对于更看重生成质量的场景，可以配置在线推理服务。

2.1 原生 MySQL 账号控制

MySQL AI UI 本身不是一个替代数据库权限系统的中间层，它更适合作为 MySQL 原生权限体系之上的分析客户端。

这意味着：

  • 应用能看到什么表、什么库，取决于当前连接使用的 MySQL 账号权限
  • 如果数据库账号本身没有某张表的 SELECT 权限，应用侧也无法绕过数据库直接访问
  • 不同业务团队可以直接复用现有的只读账号、分库账号、分环境账号
  • 生产、测试、演示环境可以通过不同 MySQL 账号天然隔离

推荐做法：

  • 生产环境为 MySQL AI UI 单独创建只读账号
  • 按业务域或项目创建不同账号，而不是所有人共用一个高权限账号
  • 将权限控制尽量下沉到 MySQL 的 GRANT 体系中，而不是依赖前端界面约束
  • 对敏感库、敏感表、敏感字段继续沿用现有数据库权限和脱敏策略

换句话说，这个项目的权限边界首先由数据库决定，应用只是遵守这条边界，而不是重新定义它。

3. 自然语言生成 SQL

这是项目最核心的工作流之一：

  1. 用户输入业务问题
  2. 应用读取当前数据库 schema
  3. AI 结合表结构、历史上下文和提示词生成 SQL
  4. 结果回填到工作台，用户可以复核并执行

生成结果不只包含 SQL，代码里还保留了这些结构化信息：

  • 组件标题建议
  • 字段中文标题建议
  • 推理摘要
  • 安全提示

这让它不只是“一次性生成 SQL”，而是在为后续保存图表、构建看板做铺垫。

4. SQL 安全控制

项目内置了只读 SQL 校验逻辑，默认限制执行内容必须是单条只读查询：

  • 仅允许 SELECT / WITH
  • 不允许注释
  • 不允许多语句执行
  • 禁止 INSERT、UPDATE、DELETE、DROP、ALTER 等危险关键字

这使它更适合作为业务分析工具，而不是数据库管理工具。

数据安全与合规思路

这个项目更适合放在“内网、本地客户端、直连企业数据库”的安全模型下理解。它的设计重点不是把权限和数据都托管到平台侧，而是尽量复用企业已经有的安全边界。

1. 数据链路尽量短

  • 应用本地运行，不要求先把 MySQL 数据同步到外部 BI 仓库
  • 默认直接连接企业自己的 MySQL
  • 如果使用本地 Ollama，AI 调用链路也可以留在本机或内网环境

这类模式更适合对数据出域敏感的场景，例如客户现场交付、私有化部署、内部经营数据分析。

2. 最小权限原则

推荐始终使用最小权限原则部署：

  • 业务分析场景优先使用只读账号
  • 不给应用连接分配 DDL、DML 权限
  • 将库级、表级权限交给 DBA 在 MySQL 中统一管理
  • 用不同账号区分生产、测试、演示环境

这样即使应用配置被误用，风险边界也仍然受数据库账号本身限制。

3. 应用层再做一层只读防护

除了依赖 MySQL 账号权限，项目内部还增加了一层只读 SQL 校验，主动拦截高风险语句。这一层不能替代数据库权限，但可以降低误操作概率，尤其适合业务用户直接提问、AI 自动生成 SQL 的场景。

4. 更容易对接现有审计与合规流程

因为它沿用的是原生 MySQL 账号、网络访问和数据库授权体系，所以通常更容易接入企业已有流程：

  • 数据库账号申请与审批
  • 堡垒机或 SSH 跳板访问
  • 数据库审计日志
  • 敏感数据分级与脱敏
  • 客户现场或私有网络环境交付

对于很多团队来说，这一点比“功能更多”更重要，因为它决定了工具能不能真正进入生产分析流程。

5. 查询结果沉淀为视图和看板

查询不止停留在执行结果页，用户还可以继续沉淀为：

  • 指标卡
  • 图表
  • 表格

然后把这些组件放进 Dashboard 页面中，形成按主题组织的业务看板，例如：

  • 经营总览
  • 渠道分析
  • 销售漏斗
  • 用户增长

6. 参数化查询

项目支持把固定 SQL 模板变成可复用查询视图，例如把日期范围、渠道、地区、业务线做成参数。

这样技术同学可以先定义一版标准模板，业务同学只需要切换参数，不必反复写 SQL。

7. 会话式分析上下文

项目不是“一问一答后就丢失上下文”的纯单轮工具。代码里包含会话与消息持久化能力，支持：

  • 保存分析对话
  • 继续基于上文追问
  • 复用同一个数据库连接下的上下文

这对连续分析场景很有帮助，例如先看趋势，再继续追问异常原因。

8. 分享与交付

项目支持分享包（share bundle）机制，可以导入或分发：

  • 数据库连接配置
  • AI 配置
  • 分享权限相关字段
  • 看板/分析资产初始化内容

这类能力很适合实施交付、模板复制和跨团队复用。

一个典型使用流程

  1. 新建并测试 MySQL 连接
  2. 配置 AI Provider 和模型
  3. 连接数据库并加载 schema
  4. 在工作台输入业务问题
  5. AI 生成 SQL，人工确认后执行
  6. 将结果保存为图表、指标卡或表格
  7. 组合成 Dashboard 页面
  8. 必要时通过分享包交付给其他团队