数据库专家Skill：把慢查询诊断、索引设计与连接池调优装进一次对话
- 一个技能覆盖四类数据库：PostgreSQL、MySQL、MongoDB、SQLite 的查询优化、模式设计、连接与事务管理都能处理，并集成 Prisma、TypeORM、Sequelize、Mongoose 等 ORM。
- 先诊断、后开方：技能会先做环境检测（连接串、配置文件、依赖、默认端口），再把问题归入六大类别，避免“上来就加索引”的盲目操作。
- 渐进式修复思路：每个问题都给出「最小化 → 更好 → 完整」三档方案，从加索引、改 JOIN 到上连接池、做零停机迁移，按团队实际能力选择。
- 安全优先：默认只读分析与 EXPLAIN 诊断，坚持不做 DROP、不带 WHERE 的 DELETE 或 TRUNCATE，模式变更前先确认备份。
- 配套代码审查清单：查询性能、模式设计、连接管理、安全验证、事务处理、迁移安全六大维度可直接用于 Code Review。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 数据库专家Skill（数据库中常简称为「数据库专家」） |
| 英文名 | database-expert |
| 技能ID | 11759 |
它解决什么问题
数据库问题最麻烦的地方往往不是“不会写 SQL”，而是定位困难：一条接口变慢，可能是缺索引、可能是 N+1 查询、可能是连接池打满、也可能是事务长时间阻塞。工程师通常要在 EXPLAIN 输出、慢查询日志、监控面板、ORM 文档之间来回切换，靠经验拼凑答案。
数据库专家Skill 把这个过程收敛成一条对话链路：它先识别你用的是哪种数据库、哪个 ORM，再判断问题属于「查询性能」「模式设计与迁移」「连接与事务」「索引与存储」「安全与访问控制」「监控与维护」中的哪一类，最后给出针对性诊断语句与渐进式修复方案。同时，它会评估是否需要路由到更专业的子专家（如 postgres-expert、mongodb-expert、redis-expert、prisma-expert、typeorm-expert），让更垂直的问题得到更垂直的答案。
一键安装思路与步骤
AI 技能的价值就在于“装上即用”，不需要你额外部署服务。通用流程如下（具体命令与入口以官方说明为准）：
- 确认安装前提：你已经在使用支持 AI 技能的客户端或开发环境（如支持技能扩展的编码助手、IDE 插件或对话式开发工具），并已登录可用账号。这些技能通常以 Markdown 技能描述文件的形式挂载，不依赖额外运行时。
- 找到技能入口：在客户端的技能市场 / 技能库 / 扩展面板中搜索技能英文名
database-expert，或直接按技能ID11759检索。 - 执行安装：点击安装或启用按钮，等待技能加载完成。若你的环境支持命令行安装，安装命令请以官方文档给出的实际命令为准。
- 验证是否生效：新建一个会话，输入一句确认性提问，例如“我在用 PostgreSQL，这条查询走了顺序扫描，帮我看看 EXPLAIN 该怎么读”。如果返回内容中出现环境检测（连接串、端口、ORM 依赖）或问题分类的判断过程，说明技能已成功加载。
- 纳入日常工作流：把它固定为数据库相关问题的默认技能，避免每次会话重复挑选。
2. 该技能的主要功能和特点
- 多数据库覆盖：针对 PostgreSQL（MVCC、VACUUM 与 ANALYZE 调度、GIN/GiST/部分索引）、MySQL（InnoDB 优化与缓冲池调优、复制与集群、存储引擎选择）、MongoDB（文档设计中的嵌入 vs 引用、聚合管道优化、分片与副本集、索引策略）、SQLite（WAL 模式、VACUUM 与完整性检查、并发访问模式）分别给出侧重不同的建议，而不是一套通用话术套所有库。
- 环境自动识别：通过连接字符串前缀（
postgresql://、mysql://、mongodb://、sqlite:///）、配置文件（postgresql.conf、my.cnf、mongod.conf）、包依赖（prisma、typeorm、sequelize、mongoose）以及默认端口（5432 / 3306 / 27017）判断技术栈，让建议贴合真实环境。 - 六大问题分类体系：每个类别都先列“常见症状”，再给“关键诊断语句”，最后给三档修复路径。例如连接类问题会先问是不是出现 “Too many connections” 或 “Connection pool exhausted”，再用
pg_stat_activity、pg_locks定位。 - 渐进式修复（Minimal → Better → Full）：同一个问题给出由浅入深三档方案。以查询性能为例，最小化方案是给 WHERE 列加索引并用 LIMIT 分页；更好方案是把子查询改写为 JOIN、配置 ORM 加载策略；完整方案才涉及性能监控、自动化优化与结果缓存。这让小团队不必一上来就搭重型基建。
- ORM 级优化建议：针对 Prisma 的连接日志事件与
include预加载、TypeORM 的eager: true关系加载等给出可直接落地的写法，专门用来消除 N+1 查询。 - 安全护栏：内置明确的安全规则——不做破坏性操作、模式变更前确认备份存在、多语句操作使用事务、诊断默认使用 SELECT 与 EXPLAIN。这一点比“让通用模型自由发挥”要稳得多。
- 结构化代码审查清单：覆盖查询性能、模式设计、连接管理、安全与验证、事务处理、迁移安全六大板块，可作为团队 Code Review 的检查表直接使用。
- 关键性能洞察沉淀：例如 PostgreSQL 每个连接约占 9MB 内存而 MySQL 每个线程约 256KB，因此 PostgreSQL 场景下连接池几乎是必选项；复合索引的列顺序应把选择性最高的列放在前面（ORDER BY 场景除外）；覆盖索引可避免回表。
3. 如何使用该技能？
步骤一：发起问题并说明环境
尽量一次性给出数据库类型、版本线索、ORM 和现象。例如：
我们用的是 PostgreSQL 14 + Prisma，最近订单列表接口 P99 从 200ms 涨到 2s，日志里没有报错。怀疑是数据量涨到 300 万行后查询变慢，帮我定位。
步骤二：让技能完成环境检测与问题分类
技能会根据你提供的信息判断数据库类型与 ORM，并把问题归入六大类别之一。如果信息不足，它会追问连接串类型、是否有配置文件或依赖清单。你也可以直接贴 schema.prisma 片段或 SHOW CREATE TABLE 的输出。
步骤三：按诊断语句收集证据
技能会给出对应的诊断语句，例如 PostgreSQL 场景：
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;
SELECT query, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
MySQL 场景：
EXPLAIN FORMAT=JSON SELECT ...;
SELECT * FROM performance_schema.events_statements_summary_by_digest;
把执行结果回贴给技能，它会解读顺序扫描、Using filesort、Using temporary 等信号，并指出瓶颈点。
步骤四：选择修复档位并落地
技能会输出三档方案。例如索引问题：
- 最小化：在过滤列上建索引，更新统计信息；
- 更好：按“选择性最高的列在前”设计复合索引，必要时用部分索引；
- 完整：引入自动化索引推荐、表达式索引或分区。
你可以根据团队现状说“先给我最小化方案”，技能会收敛到可直接执行的改动。
步骤五：验证与回归
技能会引导你做四类验证：对比优化前后的执行时间、监控连接池利用率与连接泄漏、校验约束与引用完整性、复核访问控制。上线前建议配合代码审查清单逐项自查。
步骤六：把结论沉淀成规范
把本轮诊断中有效的索引策略、池大小设置、迁移流程写进团队文档，后续同类问题可直接复用，减少重复提问。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 数据库专家Skill（database-expert） | 嵌入开发对话流程的数据库专家助手 | 环境检测、六大问题分类、三档渐进修复、ORM 优化、代码审查清单、安全护栏 | 在技能市场按英文名或技能ID安装即可，无需部署服务（以官方说明为准） | 慢查询排查、模式设计与迁移评审、连接池与事务调优、ORM N+1 治理 | 优势：诊断路径结构化、跨四种数据库、给出可执行语句且默认只读安全；不足：依赖你提供的诊断输出，无法替代真实压测与线上监控数据 |
| 直接向通用大模型提问 | 通用对话式问答 | 泛化的 SQL 与数据库知识解答 | 门槛最低，无需安装 | 偶发性的语法疑问、概念解释 | 优势：随手可用；不足：缺少环境检测与问题分类，容易给出“放之四海皆准”的答案，对连接池、迁移等场景缺少分档方案，安全性无约束 |
| 数据库原生诊断工具（EXPLAIN、pg_stat_statements、performance_schema、慢查询日志） | 数据库自带的底层诊断能力 | 执行计划、语句统计、索引使用统计、锁等待查看 | 需要开启相应扩展或参数配置，需要会读执行计划 | 精确定位单条 SQL 的瓶颈、长期性能基线采集 | 优势：最权威、最精确；不足：只提供数据不提供结论，读计划与判断修复方案仍需经验，跨数据库时语法差异大 |
| 商业数据库监控与 APM 平台 | 面向运维与 SRE 的可观测性产品 | 指标采集、慢查询趋势、告警、部分提供索引建议 | 需要部署采集端、配置账号权限，通常为商业订阅（以官方说明为准） | 生产环境长期监控、容量规划、告警响应 | 优势：可视化强、可持续跟踪；不足：偏向“发现问题”而非“给出改法”，成本与接入工作量较高，小项目性价比低 |
可以看出，数据库专家Skill 的差异化不在于“知道更多数据库知识”，而在于把诊断流程固化成可复用的方法论，并且与原生工具形成互补：原生工具出数据，它负责解读数据并给出分档方案。
5. 该技能的典型应用场景与实际体验情况
场景一：后端工程师排查线上慢查询
角色：负责订单/支付链路的后端工程师。痛点：接口 P99 忽然劣化，日志无报错，凭经验猜是索引问题但不确定。使用方式：贴出慢 SQL 与 EXPLAIN (ANALYZE, BUFFERS) 输出，技能会指出是顺序扫描还是排序开销，并给出索引方案与改写建议。实际体验：上手几乎零成本，只要会复制粘贴执行计划就能用；效果上最大的帮助是把“猜”变成“看证据”，避免了盲目加索引带来的写放大。注意点：EXPLAIN ANALYZE 会真实执行语句，生产环境请在只读库或低峰期执行。
场景二：初创团队做表结构设计与迁移评审
角色：全栈开发者兼 DBA。痛点：业务迭代快，ALTER TABLE 在大表上超时，新增非空列报 “Column cannot be null”。使用方式：让技能先看 SHOW CREATE TABLE 与约束定义，再按「最小化 → 更好 → 完整」给出迁移路径，包括先加默认值、在生产规模数据上预演、以及在支持的数据库上使用并发建索引。实际体验：迁移安全清单非常实用，尤其“提供回滚脚本”“迁移顺序依赖明确”这两条，能挡掉不少事故。注意点：技能会坚持先确认备份，不要跳过这一步。
场景三：Node.js 团队治理 ORM 的 N+1 查询
角色：使用 Prisma 或 TypeORM 的前端/全栈团队。痛点：列表接口一次请求触发上百条 SQL，数据库连接被打满。使用方式：贴出 Prisma 查询代码或实体定义，技能会建议用 include 预加载替代循环查询，或用 eager: true 配置关系加载，并给出连接日志的开启方式用于验证。实际体验：这是最容易见效的一类问题，改动通常只有几行，但对连接数的改善立竿见影。注意点：预加载会拉取更多列/行，需要与分页策略配合，避免一次加载过多关联数据。
场景四：SRE 处理连接耗尽与锁等待告警
角色：运维/SRE。痛点：出现 “Too many connections” 或 “Deadlock detected”，不确定是池太小、连接泄漏，还是长事务阻塞。使用方式：让技能给出 pg_stat_activity、pg_locks 的排查语句，区分是池配置问题还是代码未释放连接。实际体验：技能会提示 PostgreSQL 单连接约 9MB 内存这一约束，帮助判断“调大 max_connections”是否是错误方向——很多情况下正确解法是引入 PgBouncer 或 ProxySQL。注意点：池大小需要结合应用实例数与数据库内存上限计算，不能照抄数值。
6. 该技能能为用户带来的价值
效率层面：把原本需要在执行计划、慢查询日志、官方文档、ORM 手册之间来回切换的诊断路径，压缩为一次结构化对话。原本需要摸索半天的问题，往往几轮问答就能收敛到具体的索引或改写方案。
门槛层面：让不设专职 DBA 的团队也具备“像 DBA 一样思考”的路径。六大问题分类本身就是一套诊断框架，用久了工程师会形成自己的排查习惯——技能不只是给答案，还在传递方法论。
风险层面：内建的安全护栏（默认只读分析、不做破坏性操作、变更前确认备份、多语句走事务）显著降低“AI 建议被直接照抄上生产”的风险。迁移安全清单和代码审查清单，可以作为团队评审的硬性检查项。
长期价值：三档渐进修复思路契合不同阶段团队的现实——早期用最小化方案快速止血，规模化后再补齐连接池、监控与零停机迁移。同一套技能可以伴随架构一起成长，不必换工具。
7. 常见问题 FAQ
Q1：这个技能怎么安装？收费吗？
A：在支持 AI 技能的客户端或开发环境中，进入技能市场/技能库搜索英文名 database-expert 或技能ID 11759，点击安装或启用即可，无需额外部署服务。具体的安装命令、可用客户端范围与是否收费，请以官方说明为准。安装后建议用一个真实的慢查询问题验证是否生效。
Q2：它会不会直接改我的数据库？安全吗？
A：不会。技能遵循明确的安全规则：默认使用 SELECT 与 EXPLAIN 做只读诊断，不做 DROP、不带 WHERE 的 DELETE 或 TRUNCATE，多语句操作建议放在事务里，模式变更前要求确认备份存在。它输出的是诊断语句与修复建议，是否执行、如何执行由你决定。
Q3：支持哪些数据库和 ORM？只用 SQLite 会不会“大材小用”？
A：覆盖 PostgreSQL、MySQL、MongoDB 与 SQLite，ORM 侧支持 Prisma、TypeORM、Sequelize、Mongoose。SQLite 场景同样有针对性建议，例如 WAL 模式配置、VACUUM 与完整性检查、并发访问模式，并不是简单套用服务端数据库的经验。
Q4：它和直接问通用大模型有什么区别？
A：通用模型给的是通用知识，数据库专家Skill 给的是流程：先做环境检测（连接串、配置文件、依赖、端口），再做问题分类，然后给诊断语句，最后给三档修复方案，并按需路由到更垂直的子专家。此外它带有安全护栏和代码审查清单，更适合用在真实项目而不是学习场景。
Q5：它和数据库监控平台是替代关系吗？该怎么选？
A：是互补关系。监控平台擅长持续采集指标、做趋势与告警，解决“发现问题”；数据库专家Skill 擅长解读证据、给出改法，解决“解决问题”。预算与人力充足时两者都上；小团队或临时排障场景，先用技能配合数据库自带的执行计划工具，往往已经够用。