提示词商城
AI 写作
图片
视频
热门角色
热门业务
模型专用
提示词工具
×
¥元
查看详情
首页 / 查询性能优化
🔥 会员专享 文生文 工具

查询性能优化

👁️ 448 次查看
📅 Nov 24, 2025
💡 核心价值： 针对数据库查询提供优化建议，分析更改对执行时间与资源使用的影响，帮助开发者提升查询性能和系统效率，适用于全栈开发和数据库性能调优场景。

🎯 可自定义参数（5个）

数据库类型
数据库管理系统类型
查询语句
需要优化的数据库查询语句
优化目标
查询优化的主要目标
索引情况
当前数据库的索引配置情况
数据量规模
数据表中的记录数量规模

🎨 效果示例

1) 诊断与瓶颈定位（MySQL）

  • 过滤与连接顺序

    • 现有索引不包含 orders(status, created_at) 的组合，优化器通常只能用 idx_created_at(created_at) 做范围扫描，再在回表后过滤 status 与 customer_id，导致大量随机 I/O。
    • order_items 需要回表读取 quantity、unit_price 做计算；仅有单列索引 idx_order_id、idx_product_id，不能覆盖，I/O 较多。
    • products 上虽然有 idx_category，但连接路径不是固定以 category 过滤为驱动，可能从 order_items 大表驱动再过滤，放大中间结果。

  • 聚合与去重

    • 在四表连接后再 GROUP BY c.id, c.name 与 COUNT(DISTINCT o.id)，中间数据量大，易产生临时表与外部排序，CPU 与临时空间开销高。
    • COUNT(DISTINCT o.id) 在存在多条 order_items 时会触发去重开销，可通过“先按订单聚合，再按客户聚合”规避。

  • Top-N 排序

    • ORDER BY total_spent DESC LIMIT 50 是可优化的 Top-N 场景，但需要尽量在“订单级聚合后”的更小数据集上进行。

结论：缺少关键组合与覆盖索引、连接驱动不稳定、过晚聚合，是主要性能瓶颈。

2) 索引优化（DDL 与效果）

  1. orders 组合覆盖索引（高优先级）
  • DDL:
    • CREATE INDEX idx_orders_status_created_customer_id_id ON orders(status, created_at, customer_id, id);
  • 作用与原因：
    • 使条件 status IN (...) 为等值前导，created_at 为范围，形成“(status, created_at) 的范围扫描”，扫描成本远低于仅按 created_at。
    • 将 customer_id、id 纳入索引，成为覆盖索引，避免二次回表获取 join 与分组所需列。
  • 性能影响：
    • I/O：对 orders 大幅减少回表与扫描页，通常降低 50%+ 随机 I/O。
    • CPU：减少过滤行数、去重/聚合数据量，CPU 开销显著下降。
    • 执行时间：在 30 天窗口、百万级数据下，常见 2-5 倍加速。
  1. order_items 覆盖索引（高优先级）
  • DDL:
    • CREATE INDEX idx_oi_order_prod_qty_price ON order_items(order_id, product_id, quantity, unit_price);
  • 作用与原因：
    • 以 order_id 前导可在“先过滤 orders 后根据 order_id 取明细”的路径下高效定位行。
    • 覆盖 quantity、unit_price，计算 SUM(oi.quantity*oi.unit_price) 时免回表。
  • 性能影响：
    • I/O：对 order_items 的回表几乎消除，随机 I/O 大幅下降。
    • CPU：减少行访问次数，聚合更快。
    • 执行时间：明细访问通常 2-4 倍加速。
  1. products 组合索引（中优先级）
  • DDL:
    • CREATE INDEX idx_products_category_id ON products(category, id);
  • 作用与原因：
    • 按 category 过滤后，能高效产出 product_id 集合；与 order_items 按 product_id 连接时更稳定。
  • 性能影响：
    • I/O/CPU：小表索引访问更直接、减少多余扫描。
    • 执行时间：对整体收益中等，但能稳定连接顺序和减少中间结果。

说明：以上索引的列顺序是结合谓词类型（IN/等值优先，范围其次）与覆盖需求做的权衡；orders 的(status, created_at, ...) 顺序优于(created_at, status, ...)，因为 IN+范围的联合扫描更有效（先按少量 status 值分段，再按 created_at 做范围）。

3) 查询重写（聚合下推与驱动稳定）

思路：

  • 先用组合索引过滤 orders（窗口与状态），把数据量降到“订单级别”。
  • 在订单范围内，连接 order_items 与 products（按 category 过滤），并先在“订单级别”进行聚合，产出每个订单的 order_total。
  • 再按客户聚合，计算总消费与订单数；此时可以用 COUNT(*) 代替 COUNT(DISTINCT o.id)。

3.1 MySQL 8.0+ 版本（CTE）

WITH
  filtered_orders AS (
    SELECT /* 覆盖扫描 */
           o.id, o.customer_id
    FROM orders o
    FORCE INDEX (idx_orders_status_created_customer_id_id)
    WHERE o.status IN ('paid','shipped')
      AND o.created_at >= '2025-10-25'
      AND o.created_at <  '2025-11-25'
  ),
  order_totals AS (
    SELECT /* 在订单范围内做明细聚合，行数显著降低为“每单一行” */
           oi.order_id,
           SUM(oi.quantity * oi.unit_price) AS order_total
    FROM order_items oi
    JOIN filtered_orders fo
      ON fo.id = oi.order_id
    JOIN products p
      ON p.id = oi.product_id
    WHERE p.category IN ('electronics','home')
    GROUP BY oi.order_id
  ),
  by_customer AS (
    SELECT fo.customer_id,
           SUM(ot.order_total) AS total_spent,
           COUNT(*)            AS orders_count   -- 每单唯一一行，直接 COUNT(*)
    FROM filtered_orders fo
    JOIN order_totals ot
      ON ot.order_id = fo.id
    GROUP BY fo.customer_id
  )
SELECT c.id, c.name,
       bc.total_spent,
       bc.orders_count
FROM by_customer bc
JOIN customers c ON c.id = bc.customer_id
ORDER BY bc.total_spent DESC
LIMIT 50;

关键点：

  • filtered_orders 使用覆盖索引与 FORCE INDEX 稳定走(status, created_at) 组合扫描，避免回表。
  • order_totals 在订单范围内连接 products 并聚合，显著减少中间结果。此时 idx_oi_order_prod_qty_price 可覆盖明细读取。
  • 最终只对“客户级聚合结果”做 Top-50 排序，排序数据量最小。

3.2 MySQL 5.7 及以下（无 CTE，用派生表）

SELECT c.id, c.name,
       bc.total_spent,
       bc.orders_count
FROM (
  SELECT fo.customer_id,
         SUM(ot.order_total) AS total_spent,
         COUNT(*)            AS orders_count
  FROM (
    SELECT /* 先过滤订单 */
           o.id, o.customer_id
    FROM orders o
    FORCE INDEX (idx_orders_status_created_customer_id_id)
    WHERE o.status IN ('paid','shipped')
      AND o.created_at >= '2025-10-25'
      AND o.created_at <  '2025-11-25'
  ) AS fo
  JOIN (
    SELECT oi.order_id,
           SUM(oi.quantity * oi.unit_price) AS order_total
    FROM order_items oi
    JOIN products p
      ON p.id = oi.product_id
    WHERE p.category IN ('electronics','home')
    GROUP BY oi.order_id
  ) AS ot
    ON ot.order_id = fo.id
  GROUP BY fo.customer_id
) AS bc
JOIN customers c
  ON c.id = bc.customer_id
ORDER BY bc.total_spent DESC
LIMIT 50;

说明：

  • 与 CTE 版本逻辑一致。MySQL 5.7 中，子查询/派生表可能会物化，有助于稳定连接顺序与减少重复扫描。

4) 具体优化点与性能影响解析

  • 组合覆盖索引：orders(status, created_at, customer_id, id)

    • 将“状态 + 时间窗”联合定位，减少扫描页；customer_id、id 覆盖后免回表。
    • 对执行时间的影响：过滤阶段耗时大幅下降；对于百万级 orders、30 天窗口，常见 2-5 倍提速。

  • 覆盖索引：order_items(order_id, product_id, quantity, unit_price)

    • 在“先定订单集合”后，按 order_id 访问明细，读取 quantity、unit_price 时不回表。
    • 对执行时间的影响：明细读取的 I/O 降至最小，常见 2-4 倍提速。

  • 预聚合到订单级（order_totals）

    • 将“多明细行/单”压缩为“一单一行”，最终对客户聚合的输入极大减少。
    • COUNT(DISTINCT o.id) 变为 COUNT(*)，去重成本消失。
    • 对执行时间的影响：聚合代价与排序数据量都显著下降，通常 2-3 倍提速；CPU/内存/临时表写入均减少。

  • 稳定驱动顺序（通过派生表/CTE + 索引）

    • 从“已过滤的订单集合”驱动明细与商品过滤，避免从大表盲目驱动。
    • 对资源影响：中间结果更小，磁盘临时表触发概率下降。

  • 排序与 LIMIT 50

    • 在客户级聚合之后排序，MySQL 能使用 Top-N 优化（堆/partial sort），避免对全量客户结果做完全排序。
    • 对执行时间的影响：排序阶段耗时明显降低，内存占用更可控。

5) 可直接使用的优化后查询与索引

  • 建议先创建索引（在线 DDL 示例，InnoDB 默认支持；注意命名避免冲突）：
-- orders：状态 + 时间窗 + 覆盖连接列
CREATE INDEX idx_orders_status_created_customer_id_id
  ON orders(status, created_at, customer_id, id);

-- order_items：按订单驱动且覆盖计算列
CREATE INDEX idx_oi_order_prod_qty_price
  ON order_items(order_id, product_id, quantity, unit_price);

-- products：按分类快速取 product_id
CREATE INDEX idx_products_category_id
  ON products(category, id);
  • 优化后查询（MySQL 8.0+ 推荐）：
WITH
  filtered_orders AS (
    SELECT o.id, o.customer_id
    FROM orders o
    FORCE INDEX (idx_orders_status_created_customer_id_id)
    WHERE o.status IN ('paid','shipped')
      AND o.created_at >= '2025-10-25'
      AND o.created_at <  '2025-11-25'
  ),
  order_totals AS (
    SELECT oi.order_id,
           SUM(oi.quantity * oi.unit_price) AS order_total
    FROM order_items oi
    JOIN filtered_orders fo ON fo.id = oi.order_id
    JOIN products p ON p.id = oi.product_id
    WHERE p.category IN ('electronics','home')
    GROUP BY oi.order_id
  ),
  by_customer AS (
    SELECT fo.customer_id,
           SUM(ot.order_total) AS total_spent,
           COUNT(*)            AS orders_count
    FROM filtered_orders fo
    JOIN order_totals ot ON ot.order_id = fo.id
    GROUP BY fo.customer_id
  )
SELECT c.id, c.name,
       bc.total_spent,
       bc.orders_count
FROM by_customer bc
JOIN customers c ON c.id = bc.customer_id
ORDER BY bc.total_spent DESC
LIMIT 50;
  • 若需保持单条语句（不改写为 CTE），可使用派生表版本（见 3.2），同样可获得接近的收益。

6) 预期整体收益（以百万级数据为例）

  • 过滤阶段：orders 组合索引使扫描行数按“status × 时间窗”缩小；回表大幅减少。
  • 明细阶段：order_items 覆盖索引 + 先限订单集合，将无关明细行排除在外。
  • 聚合阶段：先按订单聚合，distinct 去重消失；最终仅对“客户级汇总”排序。
  • 实测场景中常见总执行时间降低 3-10 倍；临时表与文件排序概率显著降低，CPU 与 I/O 峰值更平滑。

以上优化严格围绕该查询的过滤、连接与聚合路径重构，并通过组合/覆盖索引配合，达到减少扫描、降低回表、缩小中间结果与精简聚合的目标，从而显著缩短执行时间。

MongoDB 查询优化方案（提高并发性能）

下面对给定聚合进行诊断并给出可直接应用的优化方案，包括索引设计、查询改写与执行参数调整，重点针对并发性能与总体吞吐量提升。

1. 诊断与瓶颈定位

  • 当前查询：
    • $match：按 ts 月度范围 + eventType IN 过滤
    • $group：按 userId 聚合计数和 max(ts)
    • $sort + $limit：Top 100 用户
  • 现有索引：单字段 {userId:1}、{ts:1}
  • 主要瓶颈：
    • $match 无法使用有效的复合索引：若仅用 {ts:1}，会在整个月 ts 范围内扫描大量键，再在执行器中过滤 eventType，增加 I/O 与 CPU，影响并发。
    • $group 需对大量文档按 userId 聚合，受前置过滤效率影响显著；同时内存占用与并发冲突风险上升。
    • $sort + $limit 属于 Top-N 排序，MongoDB 已自动做“受限排序”优化，但能否早期收敛取决于上游缩减量。

并发下的关键目标是：最大程度将过滤下推到索引、减少扫描量和FETCH次数、降低分组内存与I/O，从而缩短持有资源的时间。

2. 核心优化策略

A. 建立覆盖的复合索引（eventType, ts, userId）

  • 建议索引（全量或部分，二选一）：
    • 全量复合索引： 
      db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  { name: "evt_ts_user_cover" }
)
    • 部分（Partial）索引（仅覆盖 login/view/purchase）： 
      db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  {
    name: "evt_ts_user_cover_partial",
    partialFilterExpression: { eventType: { $in: ["login", "view", "purchase"] } }
  }
)
  • 原理与理由：
    • 将等值（$in 多等值）列 eventType 放在前，范围列 ts 放在后，满足“等值优先、范围随后”的索引设计原则，形成紧致的多段范围扫描（每个 eventType 一个 ts 范围）。
    • 将 group 的键（userId）包含在索引尾部，使扫描只读取索引键即可满足后续计算，最大化“覆盖查询”收益，减少文档FETCH。
  • 性能影响：
    • 执行时间：大幅下降（通常可减少扫描键数量到原来的 5%～30%，取决于事件分布与选择性）。
    • 资源使用：降低磁盘/缓存 I/O；减少 WiredTiger 锁/闩占用时间；CPU 降低（过滤在索引端完成）。
    • 并发影响：缩短每个查询持有资源的时间，吞吐量提高；部分索引还减少写入索引维护开销，降低写-读争用。

选择全量 vs 部分索引：如果查询只关心 login/view/purchase，优先使用部分索引，体积更小、维护成本更低；如果还会查询其他 eventType，再使用全量索引。

B. 改写 $match 以形成更好的索引区间（可选但常见有效）

将 $in 改写为 $or 的多个子谓词，可使优化器构造更明确的多分支范围扫描（通常与复合索引配合能得到更紧的边界）：

{ $match: {
    $or: [
      { eventType: "login",    ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
      { eventType: "view",     ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
      { eventType: "purchase", ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } }
    ]
} }
  • 性能影响：
    • 执行时间：在数据分布不均或优化器不能完美展开 $in 的版本中，常有 5%～15% 的提升。
    • 资源：略降扫描键与分支合并成本。
  • 并发：略缩短单次查询时间，边际提升吞吐。

C. 在 $match 后显式 $project 仅保留需要字段（userId, ts）

{ $project: { _id: 0, userId: 1, ts: 1 } }
  • 原理：
    • 聚合管线只传递和分组所需字段，减少内存与执行层数据拷贝。
    • 若已使用覆盖索引，上述字段均来自索引，进一步减少FETCH。
  • 性能影响：
    • 执行时间：中等规模（10万～100万行）通常 5%～10% 改善。
    • 资源：管线中间态内存与网络开销下降（若有）。

D. 在 aggregate 中使用 hint 指向复合索引

{ hint: "evt_ts_user_cover_partial" }  // 或 { eventType:1, ts:1, userId:1 }
  • 原理：
    • 确保优化器选用预期的最优索引，避免退回单列 {ts:1} 的宽范围扫描。
  • 性能/并发影响：
    • 稳定性提升，避免在负载或统计波动下出现退化计划，提升 tail latency（长尾延迟）。

E. 启用 allowDiskUse（保护并发稳定性）

  • 在可能有较大去重用户集的月份，$group 内存使用可能接近上限。为避免内存压力影响其他并发查询，可启用 allowDiskUse。
  • 取舍：
    • 执行时间：若确实溢写到磁盘，单次查询会略慢，但长尾抖动与因内存压力导致的抖动/失败大幅降低。
    • 并发：避免内存争用，提升整体稳定性与吞吐稳定性。

F. 读选项（可选）：读偏好与 readConcern

  • 若允许弱一致性：
    • 使用 readPreference: "secondary" 将读压从主节点分流。
    • readConcern: "local"（默认）即可，减少复制障碍对读延迟影响。
  • 并发影响：
    • 横向分摊读负载，显著提升并发吞吐；对实时性强的场景谨慎使用 secondary。

G. 结构性优化（中长期）：预聚合/物化视图

对月度 Top-100 的类报表查询，采用“按天按用户聚合”的物化表，运行时只需对日级摘要再聚合：

  • 日表结构：user_event_daily(userId, day, cnt, lastSeen)
  • 每日/流式汇总后，月度查询只扫描 ≤ 用户数 × 30 的记录，大幅减少扫描量与分组内存。
  • 并发影响：
    • 在线查询耗时与资源占用剧降，适合高并发场景。
    • 写端增加少量聚合/合并开销（可用定时批/流式Change Stream补数）。

3. 可直接使用的优化后查询示例

3.1 建索引（推荐：部分索引覆盖 login/view/purchase）

// 仅对 login/view/purchase 建立部分覆盖索引（更小，更快，更少写入开销）
db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  {
    name: "evt_ts_user_cover_partial",
    partialFilterExpression: { eventType: { $in: ["login", "view", "purchase"] } }
  }
);

或，如需覆盖所有事件类型：

db.actions.createIndex(
  { eventType: 1, ts: 1, userId: 1 },
  { name: "evt_ts_user_cover" }
);

3.2 优化后的聚合管线（改写 $match + 覆盖索引 + hint + allowDiskUse）

db.actions.aggregate(
[
  {
    $match: {
      $or: [
        { eventType: "login",    ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
        { eventType: "view",     ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } },
        { eventType: "purchase", ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") } }
      ]
    }
  },
  // 仅保留后续需要的字段，配合覆盖索引减少FETCH与内存传递
  { $project: { _id: 0, userId: 1, ts: 1 } },
  // 按用户聚合
  { $group: { _id: "$userId", evt_cnt: { $sum: 1 }, lastSeen: { $max: "$ts" } } },
  // Top-N 排序 + 限制
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
],
{
  allowDiskUse: true,
  hint: "evt_ts_user_cover_partial" // 或 { eventType:1, ts:1, userId:1 }
}
);

如果不想改写为 $or，仍可沿用 $in，但保留其他优化：

db.actions.aggregate(
[
  {
    $match: {
      ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-11-30") },
      eventType: { $in: ["login","view","purchase"] }
    }
  },
  { $project: { _id: 0, userId: 1, ts: 1 } },
  { $group: { _id: "$userId", evt_cnt: { $sum: 1 }, lastSeen: { $max: "$ts" } } },
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
],
{
  allowDiskUse: true,
  hint: { eventType: 1, ts: 1, userId: 1 }
}
);

3.3 可选：将查询定向至从节点（允许弱一致时）

db.getMongo().setReadPref("secondary"); // 会话级
// 或在驱动层设置 readPreference=secondary

4. 性能影响分析（逐项）

  • 覆盖复合索引 {eventType:1, ts:1, userId:1}
    • 执行时间：过滤在索引端完成；通常扫描量显著下降；Top-N 排序前的输入规模减少，整体端到端延迟降低。
    • 资源：减少磁盘与缓存I/O、降低FETCH，CPU下降；并发冲突概率降低。
  • 部分索引
    • 执行时间：同上；因索引更小，遍历更快。
    • 资源：索引体积缩小，B-Tree 更浅；写入时仅维护一棵小索引；读写争用降低。
  • $or 改写
    • 执行时间：在某些版本/分布中减少额外过滤成本，改善 5%～15%。
    • 资源：略降。
  • $project 精简列
    • 执行时间：减少管线数据体积，常见 5%～10%。
    • 资源：内存与拷贝压力下降。
  • hint 固定计划
    • 执行时间：避免退化；尤其在统计波动时稳定尾延迟。
    • 资源/并发：计划稳定减少不必要资源消耗。
  • allowDiskUse
    • 执行时间：可能略增单次耗时（如果发生溢写），但避免内存爆与抖动。
    • 并发：显著提升稳定性，避免因少数大查询挤压内存影响其他会话。

5. 中长期扩展：预聚合示例（提升高并发下的整体吞吐）

每日聚合流水（可定时任务），将原始 actions 汇总到 user_event_daily：

// 以天为粒度预聚合（可每日跑一次，或滚动窗口）
db.actions.aggregate([
  {
    $match: {
      ts: { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-12-01") },
      eventType: { $in: ["login","view","purchase"] }
    }
  },
  { $project: { userId: 1, day: { $dateTrunc: { date: "$ts", unit: "day" } }, ts: 1 } },
  {
    $group: {
      _id: { userId: "$userId", day: "$day" },
      cnt: { $sum: 1 },
      lastSeen: { $max: "$ts" }
    }
  },
  {
    $merge: {
      into: "user_event_daily",
      on: ["_id"],
      whenMatched: "merge",
      whenNotMatched: "insert"
    }
  }
], { allowDiskUse: true, hint: { eventType: 1, ts: 1, userId: 1 } });

月度 Top-100 查询只需对日表聚合：

db.user_event_daily.aggregate([
  { $match: { "_id.day": { $gte: ISODate("2025-11-01"), $lt: ISODate("2025-12-01") } } },
  {
    $group: {
      _id: "$_id.userId",
      evt_cnt: { $sum: "$cnt" },
      lastSeen: { $max: "$lastSeen" }
    }
  },
  { $sort: { evt_cnt: -1, lastSeen: -1 } },
  { $limit: 100 }
], { allowDiskUse: true });
  • 效果：运行时扫描规模从“月内所有事件条数”降为“日汇总记录数”（约 用户数 × 30），在高并发下具有数量级的性能优势。

6. 分片（如需横向扩展并发）

  • 若未来数据/并发继续增长，建议分片：
    • 读为主、按时间范围查询：range 分片键 { ts: 1 } 能将查询路由到时间范围覆盖的部分分片，减少跨分片扫描。
    • 写入和用户维度均衡：可考虑 { userId: "hashed" } 保证写均衡；但本查询按 ts 查询时会触发跨分片读（换取高并发吞吐与分布式并行）。
  • 注意：选择分片键需平衡路由精确性与写热点，生产中应结合业务写入/读取模式与分布情况评估。

7. 最终建议清单（可复用）

  1. 建立覆盖复合索引：{eventType:1, ts:1, userId:1}（优先部分索引）。
  2. 将 $match 改写为 $or（可选）以强化多段索引范围。
  3. 在 $match 后增加 $project，仅保留 userId、ts。
  4. aggregate 使用 hint 指向复合索引；开启 allowDiskUse 保障并发稳定性。
  5. 若可接受弱一致，将读定向 secondary。
  6. 中长期采用日级预聚合，显著降低在线查询压力；必要时引入分片。

以上优化可在中型数据量（1万～100万）下带来显著并发性能提升与更稳定的尾延迟表现，且兼顾后续规模扩展。

示例详情

📖 如何使用

⚡ 30秒出活：复制 → 粘贴 → 搞定
与其花几十分钟和AI聊天、试错，不如直接复制这些经过千人验证的模板，修改几个 {{变量}} 就能立刻获得专业级输出。省下来的时间，足够你轻松享受两杯咖啡！
加载中...
💬 不会填参数？让 AI 反过来问你
不确定变量该填什么？一键转为对话模式，AI 会像资深顾问一样逐步引导你，问几个问题就能自动生成完美匹配你需求的定制结果。零门槛，开口就行。
转为对话模式 →
🚀 告别复制粘贴，Chat 里直接调用
无需切换，输入 / 唤醒 8000+ 专家级提示词。 插件将全站提示词库深度集成于 Chat 输入框。基于当前对话语境，系统智能推荐最契合的 Prompt 并自动完成参数化，让海量资源触手可及，从此彻底告别"手动搬运"。
即将推出
🔌 接口一调，提示词自己会进化
手动跑一次还行，跑一百次呢？通过 API 接口动态注入变量，接入批量评价引擎，让程序自动迭代出更高质量的提示词方案。Prompt 会自己进化，你只管收结果。
发布 API →
🤖 一键变成你的专属 Agent 应用
不想每次都配参数？把这条提示词直接发布成独立 Agent，内嵌图片生成、参数优化等工具，分享链接就能用。给团队或客户一个"开箱即用"的完整方案。
创建 Agent →

✅ 特性总结

高效优化数据库查询语句，显著提升查询性能，减少执行时间和资源消耗。
智能分析查询语句，提供详细的优化建议，同时解释更改内容及其潜在影响。
支持多种数据库类型，灵活适配不同场景，让查询优化轻松高效。
自动生成专业优化解决方案，无需深厚的技术背景即可快速上手。
深入解析执行时间、资源使用等关键性能指标，帮助用户全面掌控数据库表现。
一键调用优化功能，助力开发者轻松解决查询瓶颈，专注核心业务研发。
适配复杂业务场景，提供只需简单输入即可快速生成优化方案的极致体验。

🎯 解决的问题

帮助用户快速优化数据库查询性能，提升系统运行效率并最大程度减少资源消耗，同时提供优化解释以便用户了解修改原因与其带来的性能影响。

🕒 版本历史

当前版本
v2.1 2024-01-15
优化输出结构，增强情节连贯性
  • ✨ 新增章节节奏控制参数
  • 🔧 优化人物关系描述逻辑
  • 📝 改进主题深化引导语
  • 🎯 增强情节转折点设计
v2.0 2023-12-20
重构提示词架构，提升生成质量
  • 🚀 全新的提示词结构设计
  • 📊 增加输出格式化选项
  • 💡 优化角色塑造引导
v1.5 2023-11-10
修复已知问题，提升稳定性
  • 🐛 修复长文本处理bug
  • ⚡ 提升响应速度
v1.0 2023-10-01
首次发布
  • 🎉 初始版本上线
COMING SOON
版本历史追踪，即将启航
记录每一次提示词的进化与升级，敬请期待。

💬 用户评价

4.8
⭐⭐⭐⭐⭐
基于 28 条评价
5星
85%
4星
12%
3星
3%
👤
电商运营 - 张先生
⭐⭐⭐⭐⭐ 2025-01-15
双十一用这个提示词生成了20多张海报，效果非常好！点击率提升了35%，节省了大量设计时间。参数调整很灵活，能快速适配不同节日。
效果好 节省时间
👤
品牌设计师 - 李女士
⭐⭐⭐⭐⭐ 2025-01-10
作为设计师，这个提示词帮我快速生成创意方向，大大提升了工作效率。生成的海报氛围感很强，稍作调整就能直接使用。
创意好 专业
COMING SOON
用户评价与反馈系统，即将上线
倾听真实反馈，在这里留下您的使用心得，敬请期待。
加载中...
敬请期待...