用Trae分析数据库性能瓶颈，核心诀窍只有一个：让提示词直接触发可执行的优化操作清单。它虽然不直接执行SQL，但只要提示词给得到位，它能精准生成带上下文、可复制粘贴、适配真实环境的检查与修复指令。 这里的关键在于，你得给它足够精确的上下文——数据库版本、慢SQL原文、表结构信息，一样都不能少。否则它只能给出泛泛的建议，解决不了实际问题。 那么，具体该怎么写提示词？

明确指定数据库类型与版本

提示词开头第一句，直接把数据库类型和精确版本号写清楚，比如“MySQL 8.0.33”或“PostgreSQL 15.4”。Trae会据此调取对应的语法规范和系统视图。 这里有个坑：如果你写成“MySQL最新版”，它很可能就默认用8.0的语法生成ALTER语句，结果你的生产环境是5.7，一执行就报错。 所以，直接在提示词里补上从`SELECT VERSION();`实际返回的值（比如`8.0.33-0ubuntu0.22.04.1`），比笼统写“MySQL 8.x”要可靠得多。

绑定具体表名与慢查询特征

这步有三种常见做法，可以叠加使用。 **方法一：提供完整慢SQL原文** 把你执行时间超过2秒、EXPLAIN显示type=ALL的那条SQL原样粘贴进提示词。别删减WHERE条件，也别改写字段名。Trae需要基于真实谓词判断哪些字段可以加索引、是不是需要覆盖索引。 **方法二：给出表结构关键信息** 用`DESCRIBE table_name;`或`\d table_name`输出结果中前5行字段（包含字段类型、是否允许NULL、KEY标记），外加行数（`SELECT COUNT(*) FROM table_name;`）。Trae靠这个来判断主键是否被高频查询覆盖、有没有冗余的TEXT字段在拖慢`SELECT *`。 **方法三：附带Performance Schema采样片段** 复制一段最近10分钟内，`sys.statement_analysis`视图中`rows_examined > 10000`且`a vg_latency > 500000`的记录，保留query、db、exec_count字段。Trae会据此识别出高频低效模式，比如重复执行同一个未参数化的IN查询。

强制输出纯操作清单格式

这一步是确保输出可直接执行的关键。 第一，要求Trae以编号列表输出，每条都必须是能独立执行的命令或检查动作。第二，每项开头用动词驱动，比如“执行”“创建”“删除”“检查”“修改”，禁用“建议”“考虑”“可以”这类弱动词。第三，所有SQL语句必须包含分号结尾，字段名和表名用反引号包裹（如`user_id`），避免关键字冲突。第四，非SQL动作要带上明确路径或命令，比如“查看/etc/my.cnf中`innodb_buffer_pool_size`的值”或“运行`pt-query-digest --since '2024-06-10 09:00:00' slow.log`”。 举个例子，合格的输出项应该是这样的： ① 执行：`CREATE INDEX idx_order_status_created ON orders (status, created_at) WHERE status IN ('pending', 'processing');` ② 检查：`SELECT TABLE_NAME, INDEX_LENGTH/TABLE_ROWS AS a vg_index_bytes_per_row FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'app_db' AND TABLE_ROWS > 0 ORDER BY a vg_index_bytes_per_row DESC LIMIT 3;` 只有这样精细化的提示词，Trae才能输出真正可用、拿来就能跑的操作清单。