摘要：让 AI 写 SQL 之前，先贴表结构、不要贴真实行数据，并用只读账号去试跑。本文按 MySQL SHOW CREATE TABLE、INFORMATION_SCHEMA.COLUMNS 与 MySQL/PostgreSQL 的 GRANT SELECT 整理粘贴范围和权限原则；怎么把 SQL 写对见前文。查询日期 2026-11-08。只放官网普通链接（affiliate_later）。

依据：MySQL 8.4《SHOW CREATE TABLE Statement》、MySQL 8.4《The INFORMATION_SCHEMA COLUMNS Table》、MySQL 8.4《GRANT Statement》、PostgreSQL《GRANT》、GitHub Docs《Creating automations with Copilot cloud agent》。查询日期：2026-11-08（北京时间）。只放官网/帮助中心普通链接（affiliate_later: 1）。工具可替换，不绑定某一家模型。不构成安全审计或法律意见；文中表结构和账号名都是虚构演示。

准备让 AI 帮忙写一条查询时，对话框里若只写「按客户编号汇总订单」，模型缺少列名和类型，就容易编造不存在的函数或字段。约束怎么写、正负样例和上线前怎么验收，见前文用 AI 写正则与 SQL：约束、样例与验收。怎么让模型把 SQL 写对见前文，本文只谈贴结构与权限：生成之前该往对话框里贴什么、不该贴什么，以及用来试跑的数据库账号为什么必须是只读。更泛的「哪些内容别往 AI 对话框里贴」见 AI 工具的数据隐私。

1. 该贴什么：表结构，不是行数据

MySQL 文档《SHOW CREATE TABLE Statement》的语法是 SHOW CREATE TABLE tbl_name。它会显示创建这张表的 CREATE TABLE 语句；使用这条语句，你需要对这张表拥有某种权限。文档还写明：它对视图同样有效。输出里通常能看到列名、类型、主键，以及文档举例中的 CHECK 约束（页面说明：原先写在列定义里的 CHECK，显示时会变成独立的表级约束子句）。

AI 生成 SQL 前：表结构粘贴规范与只读权限原则（2026）-有序
MySQL 8.4 文档《SHOW CREATE TABLE》：语法为 SHOW CREATE TABLE tbl_name，会显示建表语句，使用时需要对表拥有某种权限（2026-11-08 截自官方文档）

若你只想贴列清单，不一定要整段 CREATE TABLE。同一套手册里的 INFORMATION_SCHEMA.COLUMNS 提供列的元数据：COLUMN_NAME、DATA_TYPE、COLUMN_TYPE、IS_NULLABLE、COLUMN_DEFAULT，以及 COLUMN_KEY（PRI 表示主键或复合主键中的一列，UNI 表示某唯一索引的第一列，MUL 表示某非唯一索引的第一列）。文档给出一组与 SHOW COLUMNS 几乎等价的查询：

SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT
  FROM INFORMATION_SCHEMA.COLUMNS
  WHERE table_name = 'tbl_name'
  [AND table_schema = 'db_name']
  [AND column_name LIKE 'wild'];
AI 生成 SQL 前：表结构粘贴规范与只读权限原则（2026）-有序
MySQL 8.4 文档《INFORMATION_SCHEMA COLUMNS》：可查询 COLUMN_NAME、DATA_TYPE 等列元数据，而不是表里的业务行（2026-11-08 截自官方文档）

下面是一段虚构的演示输出，库名、表名和字段都是编的，用来说明你该贴的是这种结构，而不是订单明细：

SHOW CREATE TABLE demo_shop.orders\G
CREATE TABLE `orders` (
  `order_id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `customer_code` varchar(32) NOT NULL,
  `status_code` varchar(16) NOT NULL,
  `item_count` int NOT NULL,
  `created_at` datetime NOT NULL,
  PRIMARY KEY (`order_id`),
  KEY `idx_status_created` (`status_code`,`created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

把这段（或 INFORMATION_SCHEMA.COLUMNS 的查询结果）连同数据库方言（MySQL 8.4 / PostgreSQL 等）一起交给模型，它才知道主键、类型和可用的索引列。生成之后怎么用样例和官方函数表去验收，回到前文的验收清单。

2. 不该贴什么：真实行、密钥和生产可写账号

结构可以贴，下面这些不要进对话框：

  1. 整表 DUMP 或 SELECT * 的真实结果：手机号、身份证号、住址、订单金额、邮箱等行数据，模型写 SQL 用不上具体值，却可能被送进第三方服务。
  2. 连接信息：.env、主机名、端口、账号口令、连接串。
  3. 生产环境的可写账号：哪怕只是「顺手贴一下我现在的登录用户」。

GitHub 文档《Creating automations with Copilot cloud agent》在创建自动化的步骤前有一条警告：不要把密钥或其他敏感信息写进提示词；若需要让 Copilot 使用敏感值，应通过仓库密钥等机制提供，而不是写在 prompt 里。这条写的是 Copilot cloud agent 自动化场景，但「密钥不要进提示词」同样适用于你把表结构和账号信息粘贴给任何在线模型的时候。

AI 生成 SQL 前：表结构粘贴规范与只读权限原则（2026）-有序
GitHub Docs：不要把密钥或其他敏感信息写进 prompt；敏感值应通过仓库密钥等机制提供（2026-11-08 截自官方文档）

MySQL《GRANT》文档还有另一条相关提醒：在某些情况下，GRANT 可能被记进服务器日志或客户端历史文件（例如 ~/.mysql_history），明文口令因此能被有权读这些文件的人看到。给只读账号设口令、执行 CREATE USER / GRANT 时，不要把这些命令连同真实口令一起贴进 AI 对话框。

3. 只读原则：单独账号，只授 SELECT

生成出来的 SQL 可能包含 UPDATE、DELETE，或写成全表扫描。试跑时不要用生产可写账号，单独建一个只能读的用户。

MySQL《GRANT》把 SELECT 解释为允许使用 SELECT，可授在全局、数据库、表或列一级。文档里的写法包括：

GRANT SELECT ON world.* TO 'role3';
GRANT SELECT ON db2.invoice TO 'jeffrey'@'localhost';

同一页的推荐顺序是：管理员通常先用 CREATE USER 建立账号并设定口令等非权限属性，再用 GRANT 授予权限。成功后可用 SHOW GRANTS 查看实际权限。页面举例是：

CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';
GRANT ALL ON db1.* TO 'jeffrey'@'localhost';
GRANT SELECT ON db2.invoice TO 'jeffrey'@'localhost';

给 AI 试跑用的账号，不要照抄其中的 GRANT ALL。对准你要查询的库或表，只授 SELECT。用虚构名演示如下（口令不要写成真实值，也不要贴进模型）：

CREATE USER 'sql_reader'@'localhost' IDENTIFIED BY 'replace-with-a-local-secret';
GRANT SELECT ON demo_shop.* TO 'sql_reader'@'localhost';

执行后再用 SHOW GRANTS 核对：这个用户不应出现 INSERT、UPDATE、DELETE 或 ALL PRIVILEGES。官方权限表里这几项分别对应插入、更新和删除；试跑账号只要 SELECT。

AI 生成 SQL 前：表结构粘贴规范与只读权限原则（2026）-有序
MySQL 8.4《GRANT》：先 CREATE USER，再 GRANT；示例含 GRANT SELECT ON world.* 与 GRANT SELECT ON db2.invoice（2026-11-08 截自官方文档）

PostgreSQL 的 GRANT 把表级权限写成 SELECT、INSERT、UPDATE、DELETE 等，也可以一次授给某个 schema 下的全部表：

GRANT SELECT ON table_name TO role_name;
GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO role_name;

同一页的语法里还有 GRANT USAGE ON SCHEMA schema_name，以及 GRANT CONNECT ON DATABASE database_name。只给了表上的 SELECT、却没有对应 schema 的 USAGE 时，角色可能连表都访问不到，需要按你当前 PostgreSQL 版本文档把这几级权限一起核对比。文档还提醒：超级用户可以访问所有对象，不管对象权限如何设置；除了确实必要的时候，不要用超级用户来日常操作。另外，给表授权并不会自动延伸到表所使用的序列（包括 SERIAL 列关联的序列），序列权限要单独设置。

AI 生成 SQL 前：表结构粘贴规范与只读权限原则（2026）-有序
PostgreSQL 18《GRANT》语法：可对表授予 SELECT，也可使用 ALL TABLES IN SCHEMA（2026-11-08 截自官方文档）

试跑地点选只读副本，或本地一份已经脱敏的拷贝，而不是生产主库的可写连接。生成结果仍要人工看过再考虑是否在更大范围执行；这一步的样例和验收回到前文。

4. 生成前可以勾的几项

[ ] 贴出去的是 SHOW CREATE TABLE 或 INFORMATION_SCHEMA.COLUMNS 一类结构，不是 SELECT * 的真实行
[ ] 演示用的库名、表名、字段是虚构或已脱敏的，对话框里没有 .env、连接串和口令
[ ] 用来试跑的账号只有 SELECT（MySQL 可用 SHOW GRANTS 核对）
[ ] PostgreSQL 时同时核对表级 SELECT、schema 的 USAGE、数据库的 CONNECT
[ ] 试跑发生在只读副本或本地脱敏库，不是生产可写账号
[ ] 生成之后的约束、样例和验收，按前文清单做，不把模型输出直接当上线语句

风险与范围

本文不是安全审计、合规审查或法律意见。各公司对生产数据、提示词和外部模型往往另有内部规定，以你所在团队的规定为准。GRANT、CREATE USER 的完整语法、角色激活方式和副本搭建步骤，都以你正在使用的数据库版本官方文档为准，本文不编造未在上述页面出现的权限名。示例中的 demo_shop.orders 与 sql_reader 均为虚构。

相关阅读