很多团队都遇到过同一个问题：
业务天天提分析需求，研发天天帮忙写 SQL。
产品想看转化漏斗，运营想看活动效果，老板想看经营数据，最后都绕回一句话：
“谁帮我查一下数据库？”
问题不是没有数据。
问题是，数据虽然在 MySQL 里，但真正能顺手把它用起来的人，通常只有少数会写 SQL 的同学。
于是我一直在想，有没有一种更轻一点的方式：
- 不用上来就部署一套复杂 BI
- 不用把数据搬进第三方 SaaS
- 不用让业务同学先学会 SQL
- 但又能把“提问题 -> 查数据 -> 做图表 -> 变看板”这件事串起来
所以就有了这个项目：MyAiSQL。
它本质上是一个本地桌面工具，面向 MySQL 场景，把这些能力放到一起：
- 直连 MySQL
- 自然语言生成 SQL
- 只读安全校验
- 查询结果沉淀为图表和指标卡
- 组合成轻量 Dashboard
- 支持参数化和分享交付
你可以把它理解成：
一个更适合中小团队、更强调数据不出域的“AI 查询 + 轻量 BI”组合。
为什么我要做这个东西？
因为我发现很多团队其实卡在一个很尴尬的位置。
如果完全靠数据库客户端，业务同学用不起来。
如果直接上成熟 BI，往往又太重、太贵、太慢。
如果用云端 AI 工具，又会碰到一个现实问题：
数据能不能出去？
特别是在客户现场、私有化项目、内网环境、经营数据场景里，大家最关心的从来不只是“能不能查出来”，而是：
- 数据会不会出域
- 权限边界清不清楚
- 有没有审计路径
- 能不能复用现有数据库账号体系
这也是 MyAiSQL 的一个核心思路：
尽量不发明新的安全边界，而是复用企业原本就有的边界。
它适合什么团队？
我觉得它特别适合下面几类团队。
1. 没有完整 BI 团队，但分析需求很多的团队
这种团队最常见。
公司有数据库，也有业务数据，但没有专门的数据平台团队。结果就是：
- 产品遇到问题先找研发
- 运营想看数据先找研发
- 老板要报表也找研发
研发最后变成“半个数据支持团队”。
这种情况下，一个能直接连 MySQL、还能让业务自己提问的工具，价值就很直接。
2. 不想把核心数据上传到外部平台的团队
有些团队不是没有钱买工具，而是不能接受把核心业务数据送到外部平台。
尤其是：
- 客户项目
- 私有化部署
- 金融/医疗/政企类场景
- 对经营数据敏感的公司
这种时候，“本地运行、直连数据库、尽量不出域”就不是加分项，而是前提条件。
3. 需要交付模板化分析能力的实施团队
除了自己用，我觉得这个项目还挺适合“交付”。
因为很多实施项目不是要做一个超大的平台，而是希望把一套标准能力快速复制给不同客户环境，比如：
- 一套连接配置
- 一套 AI 配置
- 一套标准查询模板
- 一套经营分析 Dashboard
如果这些东西可以打包、导入、复用，交付效率会高很多。
它到底解决了什么问题？
如果用一句话概括，我觉得它解决的是：
让“会写 SQL 的人”先搭好分析能力，再让“不会写 SQL 的人”也能把数据用起来。
这里面其实有两层价值。
第一层：降低查询门槛
以前你想查“最近 7 天每天订单量”，你得自己写 SQL。
现在你可以先用自然语言提问，让 AI 帮你生成 SQL，再人工确认执行。
这件事的价值不只是“省几分钟”，而是让很多本来提不出、查不了、懒得查的问题，变得更容易被提出和验证。
第二层：把一次性查询沉淀成长期资产
真正有价值的分析，不是一次查出来就结束，而是要沉淀成：
- 指标卡
- 图表
- 表格
- Dashboard 页面
- 参数化模板
这样业务下次就不用再从头提问，而是直接打开一个看板，切换时间、渠道、地区就能看。
这也是我很在意的一点：
AI 不能只是“帮你生成一次 SQL”，还得帮你把结果变成可复用的分析资产。
它是怎么工作的？
整个流程其实很直观：
- 配置 MySQL 连接
- 配置 AI Provider
- 读取 schema，让模型理解库表结构
- 输入自然语言问题
- 生成 SQL
- 做只读安全校验
- 执行查询
- 保存为图表、指标卡或表格
- 组合成 Dashboard
这个流程看起来普通，但真正关键的是中间那几步：
schema 不只是“展示结构”，而是 AI 理解数据库的上下文
模型之所以能生成相对靠谱的 SQL，不是凭空猜，而是建立在 schema 上下文基础上的。
它需要知道：
- 有哪些表
- 字段叫什么
- 表之间可能怎么关联
- 哪些字段更像时间、金额、用户、订单
所以这个项目并不是单纯做一个聊天框，而是尽量把数据库上下文带给模型。
SQL 生成之后，不是直接执行，而是先过安全校验
这是很重要的一层保护。
默认情况下，它更偏向“分析工具”而不是“数据库管理工具”，所以执行层面会限制为只读查询，比如：
- 只允许 SELECT / WITH
- 不允许多语句
- 不允许注释
- 拦截 INSERT、UPDATE、DELETE、DROP、ALTER 等高风险语句
这能减少 AI 误生成或用户误执行带来的风险。
为什么我会特别强调“数据安全”这件事？
因为一旦涉及数据库和 AI，安全问题绕不过去。
很多人第一反应会问：
“你这个是不是会把我的数据库数据传出去？”
这个问题不能靠一句“我们很安全”来回答，而是要拆开看。
1. 它是本地客户端，不是云端托管平台
也就是说，它不是先把你的 MySQL 数据同步到一个第三方平台，再让你去分析。
它的基本模式是：
本地运行，直连你自己的 MySQL。
这意味着数据链路更短，边界也更清楚。
2. 权限边界优先复用 MySQL 原生账号体系
我一直觉得，一个分析工具最稳妥的做法，不是自己再造一套复杂权限系统，而是老老实实复用数据库原生权限。
也就是说：
- 能查哪些库、哪些表，先由 MySQL 账号决定
- 没有权限的表，工具也看不到
- 生产、测试、演示环境可以天然隔离
- 不同团队可以继续使用不同只读账号
这比在应用层重新设计一套“谁能看什么”更符合企业现实。
3. 应用层再加一层只读保护
数据库权限是第一层，应用只读校验是第二层。
这两层结合起来，才是比较稳的安全模型：
- 数据库账号限制“本来能干什么”
- 应用限制“这次允许执行什么”
尤其在 AI 参与生成 SQL 的情况下，这层保护很有必要。
4. 如果特别在意数据出域，可以优先走本地模型
项目现在支持多个 Provider，包括在线模型，也包括本地 Ollama。
这意味着你可以根据场景选择：
- 想要生成质量更高，可以接在线服务
- 想要更强的数据边界控制，可以优先本地模型或内网模型
所以“会不会出域”，不是一个非黑即白的问题，而是和你的模型部署方式直接相关。
它的数据合规性应该怎么理解？
我觉得这类产品谈合规，最忌讳说空话。
它不是一个“替你完成合规”的神奇平台。
更准确地说，它是一个更容易纳入现有合规体系的分析客户端。
为什么这么说？
因为它复用的是企业已经存在的那套机制：
- MySQL 账号权限
- 堡垒机 / SSH 跳板
- 数据库审计日志
- 敏感字段脱敏
- 环境隔离
- 内网/私网网络边界
这意味着你不需要为了上这个工具，重新设计一套全新的权限与审计流程。
对于很多企业来说，这点非常重要。
因为“能不能接进现有流程”，往往比“功能是不是更炫”更决定一个工具能不能落地。
它不适合什么场景？
这个也得说清楚。
我不觉得它适合替代所有东西。
它更适合的是：
- 轻量分析
- 业务自助查询
- 看板沉淀
- 私有化分析客户端
- 模板化交付
但它不太适合直接替代这些系统：
- 企业级数据中台
- 完整的数据治理平台
- 专业 BI 平台的全部能力
- 数据开发调度体系
- 数据库运维工具
换句话说，它不是要做“大而全”，而是想把一个高频、刚需、容易卡住的环节做顺：
让业务更容易拿到数据，让技术不再一直被临时 SQL 拖住。
我觉得它最适合的落地方式是什么？
不是一上来就让所有业务同学自由提问。
我更推荐一种“技术先搭、业务再用”的方式。
第一步：技术或数据同学先做基础建设
先把这些东西准备好：
- 数据库连接
- 只读账号
- AI 配置
- 核心表结构理解
- 标准查询模板
- 标准 Dashboard
第二步：业务同学基于模板来使用
这样业务侧主要做的是：
- 提问题
- 看结果
- 切参数
- 看图表
- 做复盘
而不是从零开始摸索字段含义和指标口径。
这其实是很多团队最现实、最稳妥的落地路径。
最后
我做这个项目时，想解决的从来不是“AI 能不能写 SQL”这么单一的问题。
真正想解决的是：
数据已经在 MySQL 里了，团队能不能以更低门槛、更安全、更可沉淀的方式把它用起来。
如果一个工具能同时满足下面几点，我觉得它就有实际价值：
- 业务能更容易提问题
- 技术不用反复救火写 SQL
- 数据尽量不出域
- 权限边界依然清楚
- 查询结果能沉淀成长期资产
- 不需要为了它再上一个很重的平台
而 MyAiSQL，基本就是沿着这个方向在做。
如果你也在做类似场景，比如：
- 私有化数据分析
- AI + SQL
- 轻量 BI
- 本地桌面分析工具
- 面向交付的模板化分析能力
欢迎继续交流 项目主页：https://www.opcpu.com/project/aimysql
