MyAiSQL是什么？

Q1：MyAiSQL是什么？
A：它是一个面向 MySQL 场景的本地桌面数据分析工具，把“数据库连接、自然语言转 SQL、查询分析、图表看板、模板分享”放在一个应用里。它不是云端 SaaS，也不是要替代数据库，而是帮助团队在本地直连自己的 MySQL 数据库完成分析工作。

Q2：它适合什么情况下使用？
A：比较适合下面几类场景：
- 团队已经有 MySQL 数据，但分析还严重依赖研发临时写 SQL
- 产品、运营、业务负责人经常提分析需求，但不会写 SQL
- 团队不想上重型 BI 平台，或者觉得传统 BI 成本高、实施慢
- 企业对数据出域敏感，不希望把核心业务数据上传到第三方平台
- 需要做客户现场交付、私有化部署、内网分析或模板复用

Q3：哪些人适合使用？
A：
- 产品经理、运营、业务负责人：提业务问题、看报表、做复盘
- 数据同学、研发同学：配置连接、校验 SQL、沉淀标准模板
- 实施顾问、交付团队：把一套分析模板交付到不同客户环境
- 中小团队管理者：快速搭建轻量分析体系

Q4：它的核心价值是什么？
A：
- 让不会写 SQL 的同学也能更快得到查询结果
- 保留 MySQL 直连模式，不强制把数据搬到外部平台
- 可以把一次性查询沉淀成指标卡、图表和 Dashboard
- 支持参数化查询，方便业务同学按条件复用
- 支持分享和交付，适合模板化复制

Q5：典型使用流程是什么？
A：
1. 配置并测试 MySQL 连接
2. 配置 AI 模型
3. 输入业务问题，生成 SQL
4. 人工确认 SQL 后执行
5. 将结果保存成图表、指标卡或表格
6. 组合成 Dashboard
7. 需要时导出或分享给其他团队/客户环境

Q6：它的数据安全性怎么样？
A：这个产品的安全设计重点是“数据尽量不出域、链路尽量短”。
- 应用本地运行，不要求先把数据同步到外部 SaaS
- 直接连接企业自己的 MySQL
- 连接信息、AI 配置和应用状态默认保存在本地用户目录
- 如果使用本地 Ollama，AI 推理链路也可以留在本机或内网

所以它更适合对数据外发敏感的企业环境，例如内网、私有网络、客户现场。

Q7：它会不会把数据库数据上传出去？
A：默认设计不是“把整库上传到平台”。它是本地客户端直连数据库。
但需要注意：
- 如果使用在线 AI Provider，例如 Kimi、DeepSeek，和模型交互时，相关上下文内容可能会发送到对应模型服务
- 如果使用本地 Ollama，则可以进一步降低数据出域风险

也就是说，是否“出域”与所选 AI Provider 有直接关系。

Q8：它的数据合规性如何理解？
A：它本身更像一个“遵守企业现有边界”的分析客户端，而不是重新定义一套数据治理体系。它的合规优势主要在于：
- 复用企业已有的 MySQL 账号权限体系
- 可以沿用数据库审计、堡垒机、SSH 跳板等既有流程
- 可以继续使用企业现有的敏感字段脱敏和权限隔离策略
- 更容易放进已有的数据申请、审批和审计流程中

换句话说，它的合规性主要取决于“企业如何配置数据库权限、网络边界和模型使用方式”，而不是应用单独承诺替代这些制度。

Q9：它怎么做权限控制？
A：它优先复用 MySQL 原生账号权限，而不是自己再造一套复杂权限系统。
- 能查哪些库、哪些表，首先由 MySQL 账号权限决定
- 没有数据库 `SELECT` 权限的表，应用也无法绕过访问
- 不同团队可以使用不同只读账号、分环境账号、分业务域账号
- 生产、测试、演示环境可以天然隔离

这是比较符合企业治理习惯的做法。

Q10：它如何降低误操作风险？
A：项目内置了一层只读 SQL 安全校验。
- 默认仅允许 `SELECT` / `WITH`
- 不允许多语句执行
- 不允许注释
- 会拦截 `INSERT`、`UPDATE`、`DELETE`、`DROP`、`ALTER` 等高风险语句

这意味着它更适合作为“分析工具”，而不是数据库运维工具。

Q11：只靠应用层校验就够了吗？
A：不够。更稳妥的做法是“双保险”：
- 第一层：MySQL 账号本身只给只读权限
- 第二层：应用侧只读 SQL 校验再拦一次

推荐始终以数据库权限为主，应用校验为辅。

Q12：推荐怎么做安全部署？
A：
- 生产环境单独创建只读账号
- 不要给应用连接 DDL、DML 权限
- 按业务域、项目、环境拆分账号
- 对敏感表、敏感字段继续使用现有脱敏策略
- 对高敏场景优先使用本地 Ollama 或内网模型服务
- 将数据库访问继续纳入现有审计流程

Q13：这个产品适合哪些合规敏感场景？
A：相对适合以下场景：
- 私有化部署
- 客户现场实施
- 内网经营分析
- 不希望核心数据进入第三方 BI SaaS 的团队
- 希望沿用现有数据库审计和权限体系的企业

但如果企业对“模型侧数据调用”要求极高，就应该优先使用本地模型或内网推理服务，而不是公网模型。

Q14：业务同学可以直接用吗？
A：可以，但更推荐“技术先搭，业务再用”。
- 技术或数据同学先配置连接、模型、口径和模板
- 业务同学再基于自然语言提问、看板查看、参数切换来使用

这样更容易保证指标口径一致，减少误解和误查。

Q15：它更适合替代什么，不适合替代什么？
A：它更适合替代：
- 临时找研发写 SQL 的低效分析流程
- 轻量 BI 和经营分析的早期搭建工作
- 一部分内部数据看板和交付模板场景

它不适合直接替代：
- 企业级数据中台
- 复杂主数据治理平台
- 专业数据库管理/运维系统
- 完整的权限审计与合规平台本身

Q16：一句话怎么介绍这个产品？
A：
MyAiSQL 是一个面向 MySQL 的本地智能分析客户端，适合在数据不出域的前提下，用自然语言快速生成 SQL、沉淀业务看板，并复用企业现有的数据库权限和合规体系。