sql-pro
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSQL Pro
SQL Pro
Purpose
用途
Provides expert SQL development capabilities across major database platforms (PostgreSQL, MySQL, SQL Server, Oracle), specializing in complex query design, performance optimization, and database architecture. Masters ANSI SQL standards, platform-specific optimizations, and modern data patterns with focus on efficiency and scalability.
提供跨主流数据库平台(PostgreSQL、MySQL、SQL Server、Oracle)的专业SQL开发能力,专注于复杂查询设计、性能优化和数据库架构。精通ANSI SQL标准、平台特定优化以及现代数据模式,重点关注效率和可扩展性。
When to Use
适用场景
- Writing complex SQL queries with joins, CTEs, window functions, or recursive queries
- Designing database schema for new application or refactoring existing schema
- Optimizing slow SQL queries with execution plan analysis
- Data migration between different database platforms (MySQL → PostgreSQL)
- Implementing stored procedures, functions, or triggers
- Building analytical reports with advanced aggregations and window functions
- Translating business requirements into SQL query logic
- Cross-platform SQL compatibility issues (different dialects)
- 编写包含连接、CTE、窗口函数或递归查询的复杂SQL语句
- 为新应用设计数据库架构或重构现有架构
- 通过执行计划分析优化缓慢的SQL查询
- 在不同数据库平台之间进行数据迁移(如MySQL → PostgreSQL)
- 实现存储过程、函数或触发器
- 使用高级聚合和窗口函数构建分析报告
- 将业务需求转化为SQL查询逻辑
- 跨平台SQL兼容性问题(不同方言)
Quick Start
快速入门
Invoke this skill when:
- Writing complex queries with CTEs, window functions, or recursive patterns
- Designing or refactoring database schemas
- Optimizing slow queries with execution plan analysis
- Migrating data between different database platforms
- Implementing stored procedures, functions, or triggers
- Building analytical reports with advanced aggregations
Do NOT invoke when:
- PostgreSQL-specific features needed → Use postgres-pro
- MySQL-specific administration → Use database-administrator
- Simple CRUD operations → Use backend-developer
- ORM query patterns → Use appropriate language skill
当以下情况时调用此技能:
- 编写包含CTE、窗口函数或递归模式的复杂查询
- 设计或重构数据库架构
- 通过执行计划分析优化缓慢的查询
- 在不同数据库平台之间进行数据迁移
- 实现存储过程、函数或触发器
- 使用高级聚合构建分析报告
请勿在以下情况调用:
- 需要PostgreSQL特定功能 → 使用postgres-pro
- MySQL特定管理操作 → 使用database-administrator
- 简单CRUD操作 → 使用backend-developer
- ORM查询模式 → 使用对应语言技能
Decision Framework
决策框架
CTE vs Subquery vs JOIN Decision Tree
CTE vs 子查询 vs JOIN 决策树
Query Requirement Analysis
│
├─ Need to reference result multiple times?
│ └─ YES → Use CTE (avoids duplicate subquery evaluation)
│ WITH user_totals AS (SELECT ...)
│ SELECT * FROM user_totals WHERE ...
│ UNION ALL
│ SELECT * FROM user_totals WHERE ...
│
├─ Recursive data traversal (hierarchy, graph)?
│ └─ YES → Use Recursive CTE (ONLY option for recursion)
│ WITH RECURSIVE tree AS (
│ SELECT ... -- anchor
│ UNION ALL
│ SELECT ... FROM tree ... -- recursive
│ )
│
├─ Simple lookup or filter?
│ └─ Use JOIN (most optimizable by query planner)
│ SELECT u.*, o.total
│ FROM users u
│ JOIN orders o ON u.id = o.user_id
│
├─ Correlated subquery in WHERE clause?
│ ├─ Checking existence → Use EXISTS (stops at first match)
│ │ WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = u.id)
│ │
│ └─ Value comparison → Use JOIN instead
│ -- BAD: WHERE (SELECT COUNT(*) FROM orders WHERE user_id = users.id) > 5
│ -- GOOD: JOIN (SELECT user_id, COUNT(*) as cnt FROM orders GROUP BY user_id)
│
└─ Readability vs Performance trade-off?
├─ Complex logic, readability critical → CTE
│ (Easier to understand, debug, maintain)
│
└─ Performance critical, simple logic → Subquery or JOIN
(Query planner can inline and optimize)Query Requirement Analysis
│
├─ Need to reference result multiple times?
│ └─ YES → Use CTE (avoids duplicate subquery evaluation)
│ WITH user_totals AS (SELECT ...)
│ SELECT * FROM user_totals WHERE ...
│ UNION ALL
│ SELECT * FROM user_totals WHERE ...
│
├─ Recursive data traversal (hierarchy, graph)?
│ └─ YES → Use Recursive CTE (ONLY option for recursion)
│ WITH RECURSIVE tree AS (
│ SELECT ... -- anchor
│ UNION ALL
│ SELECT ... FROM tree ... -- recursive
│ )
│
├─ Simple lookup or filter?
│ └─ Use JOIN (most optimizable by query planner)
│ SELECT u.*, o.total
│ FROM users u
│ JOIN orders o ON u.id = o.user_id
│
├─ Correlated subquery in WHERE clause?
│ ├─ Checking existence → Use EXISTS (stops at first match)
│ │ WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = u.id)
│ │
│ └─ Value comparison → Use JOIN instead
│ -- BAD: WHERE (SELECT COUNT(*) FROM orders WHERE user_id = users.id) > 5
│ -- GOOD: JOIN (SELECT user_id, COUNT(*) as cnt FROM orders GROUP BY user_id)
│
└─ Readability vs Performance trade-off?
├─ Complex logic, readability critical → CTE
│ (Easier to understand, debug, maintain)
│
└─ Performance critical, simple logic → Subquery or JOIN
(Query planner can inline and optimize)Window Function vs GROUP BY Decision Matrix
窗口函数 vs GROUP BY 决策矩阵
| Requirement | Solution | Example |
|---|---|---|
| Need aggregation + row-level detail | Window function | |
| Only aggregated results needed | GROUP BY | |
| Ranking/row numbering | Window function (ROW_NUMBER, RANK, DENSE_RANK) | |
| Running totals / moving averages | Window function with frame | |
| LAG/LEAD (access previous/next rows) | Window function | |
| Percentile / NTILE | Window function | |
| Simple count/sum/avg by group | GROUP BY (more efficient) | |
| 需求 | 解决方案 | 示例 |
|---|---|---|
| 需要聚合+行级细节 | 窗口函数 | |
| 仅需聚合结果 | GROUP BY | |
| 排名/行号生成 | 窗口函数(ROW_NUMBER, RANK, DENSE_RANK) | |
| 累计总和/移动平均值 | 带框架的窗口函数 | |
| LAG/LEAD(访问前/后行) | 窗口函数 | |
| 百分位数/NTILE | 窗口函数 | |
| 按组进行简单计数/求和/平均 | GROUP BY(更高效) | |
Red Flags → Escalate to Oracle
预警信号 → 升级至Oracle专家
| Observation | Why Escalate | Example |
|---|---|---|
| Cartesian product in execution plan | Unintended cross join causing exponential rows | "Query returning millions of rows" |
| Complex multi-level recursive CTE performance | Advanced optimization needed | "Recursive CTE traversing 10+ levels with 100K nodes" |
| Cross-platform migration with incompatible features | Platform-specific feature mapping | "Migrating Oracle CONNECT BY to PostgreSQL recursive CTE" |
| Query with 10+ joins and complex logic | Architecture smell, potential redesign | "Single query joining 15 tables" |
| Temporal query with complex time-series logic | Advanced analytical pattern | "SCD Type 2 with historical snapshots" |
| 现象 | 升级原因 | 示例 |
|---|---|---|
| 执行计划中出现笛卡尔积 | 意外的交叉连接导致行数呈指数级增长 | "查询返回数百万行数据" |
| 复杂多层递归CTE性能问题 | 需要高级优化 | "递归CTE遍历10+层级、10万+节点" |
| 包含不兼容特性的跨平台迁移 | 需要平台特定特性映射 | "将Oracle CONNECT BY迁移至PostgreSQL递归CTE" |
| 包含10+个连接和复杂逻辑的查询 | 架构问题,可能需要重构 | "单个查询连接15张表" |
| 包含复杂时间序列逻辑的时态查询 | 高级分析模式需求 | "带历史快照的SCD Type 2" |
Core Capabilities
核心能力
Advanced Query Patterns
高级查询模式
- Common Table Expressions (CTEs) and recursive queries
- Window functions: ROW_NUMBER, RANK, LEAD, LAG, aggregate windows
- PIVOT/UNPIVOT operations for data transformation
- Hierarchical queries for tree/graph structures
- Temporal queries for time-based analysis
- 通用表表达式(CTE)和递归查询
- 窗口函数:ROW_NUMBER、RANK、LEAD、LAG、聚合窗口
- PIVOT/UNPIVOT数据转换操作
- 用于树/图结构的层级查询
- 用于基于时间分析的时态查询
Query Optimization
查询优化
- Execution plan analysis and interpretation
- Index selection strategies and covering indexes
- Statistics management and maintenance
- Query hints and plan guides (when necessary)
- Parallel query execution tuning
- 执行计划分析与解读
- 索引选择策略与覆盖索引
- 统计信息管理与维护
- 查询提示与计划指南(必要时)
- 并行查询执行调优
Index Design Patterns
索引设计模式
- Clustered vs. non-clustered indexes
- Covering indexes for query optimization
- Filtered/partial indexes for selective queries
- Function-based/indexes on expressions
- Composite index column ordering
- 聚集索引 vs 非聚集索引
- 用于查询优化的覆盖索引
- 针对选择性查询的过滤/部分索引
- 基于表达式的函数型索引
- 复合索引列排序
Quality Checklist
质量检查清单
Query Performance:
- Execution time meets requirements (OLTP: <100ms, Analytics: <5s)
- EXPLAIN ANALYZE reviewed for all complex queries
- No sequential scans on large tables (unless intended)
- Indexes utilized effectively (check execution plan)
- No N+1 query patterns (correlated subqueries eliminated)
SQL Quality:
- Only necessary columns in SELECT (no SELECT *)
- Explicit table aliases used in multi-table queries
- Proper NULL handling (COALESCE, IS NULL vs = NULL)
- Data types match in comparisons (no implicit conversions)
- Parameterized queries used (SQL injection prevention)
Optimization:
- Window functions used instead of self-joins where applicable
- EXISTS used instead of NOT IN for better NULL handling
- Covering indexes suggested for frequent queries
- Query rewritten to eliminate correlated subqueries
Documentation:
- Complex query logic explained in comments
- CTE names descriptive and self-documenting
- Expected output format documented
- Performance characteristics documented
查询性能:
- 执行时间符合要求(OLTP:<100ms,分析型:<5s)
- 所有复杂查询均已通过EXPLAIN ANALYZE审核
- 大表无全表扫描(除非有意为之)
- 索引得到有效利用(检查执行计划)
- 消除了N+1查询模式(关联子查询已移除)
SQL质量:
- SELECT语句仅包含必要列(无SELECT *)
- 多表查询中使用明确的表别名
- 正确处理NULL值(使用COALESCE、IS NULL而非= NULL)
- 比较操作中数据类型匹配(无隐式转换)
- 使用参数化查询(防止SQL注入)
优化项:
- 适用场景下使用窗口函数替代自连接
- 使用EXISTS而非NOT IN以更好处理NULL值
- 为频繁查询建议覆盖索引
- 重写查询以消除关联子查询
文档:
- 复杂查询逻辑已在注释中说明
- CTE名称具有描述性且自文档化
- 已记录预期输出格式
- 已记录性能特征
Additional Resources
额外资源
- Detailed Technical Reference: See REFERENCE.md
- Code Examples & Patterns: See EXAMPLES.md
- 详细技术参考:参见REFERENCE.md
- 代码示例与模式:参见EXAMPLES.md