Add comprehensive SQL and PostgreSQL prompt collection
- Add sql-code-review.prompt.md: Universal SQL code review for security, maintainability, and quality standards - Add sql-optimization.prompt.md: Universal SQL performance optimization for query tuning and indexing - Add postgresql-code-review.prompt.md: PostgreSQL-specific code review focusing on PG best practices and anti-patterns - Add postgresql-optimization.prompt.md: PostgreSQL-specific development assistant for unique PG features (JSONB, arrays, custom types) This creates a complete 4-prompt ecosystem with zero overlap: - Universal SQL (code quality + performance) for cross-database compatibility - PostgreSQL-specific (code quality + performance) for PG-exclusive features Each prompt serves distinct, isolated purposes while complementing each other for comprehensive SQL development support.
This commit is contained in:
shubham070
parent
407e2a4faf
commit
e0d87f7415
@ -110,7 +110,11 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [My Issues](prompts/my-issues.prompt.md) | List my issues in the current repository | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-issues.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-issues.prompt.md) |
|
||||
| [My Pull Requests](prompts/my-pull-requests.prompt.md) | List my pull requests in the current repository | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-pull-requests.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-pull-requests.prompt.md) |
|
||||
| [Next Intl Add Language](prompts/next-intl-add-language.prompt.md) | Add new language to a Next.js + next-intl application | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fnext-intl-add-language.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fnext-intl-add-language.prompt.md) |
|
||||
| [PostgreSQL Code Review Assistant](prompts/postgresql-code-review.prompt.md) | PostgreSQL-specific code review focusing on PostgreSQL best practices, anti-patterns, and PostgreSQL-unique quality standards. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-code-review.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-code-review.prompt.md) |
|
||||
| [PostgreSQL Development Assistant](prompts/postgresql-optimization.prompt.md) | PostgreSQL-specific development assistant focusing on unique PostgreSQL features, advanced data types, and PostgreSQL-exclusive capabilities. Complements general SQL optimization and code review. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-optimization.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-optimization.prompt.md) |
|
||||
| [Review And Refactor](prompts/review-and-refactor.prompt.md) | Review and refactor code in your project according to defined instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Freview-and-refactor.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Freview-and-refactor.prompt.md) |
|
||||
| [SQL Code Review](prompts/sql-code-review.prompt.md) | Universal SQL code review focusing on security, maintainability, and code quality standards across all SQL databases. Complements SQL optimization prompt. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-code-review.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-code-review.prompt.md) |
|
||||
| [SQL Performance Optimization Assistant](prompts/sql-optimization.prompt.md) | Universal SQL performance optimization assistant for query tuning, indexing strategies, and database performance across all SQL databases. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-optimization.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-optimization.prompt.md) |
|
||||
| [Suggest Awesome GitHub Copilot Chatmodes](prompts/suggest-awesome-github-copilot-chatmodes.prompt.md) | Suggest relevant GitHub Copilot chatmode files from the awesome-copilot repository based on current repository context and chat history, avoiding duplicates with existing chatmodes in this repository. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-chatmodes.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-chatmodes.prompt.md) |
|
||||
| [Suggest Awesome GitHub Copilot Prompts](prompts/suggest-awesome-github-copilot-prompts.prompt.md) | Suggest relevant GitHub Copilot prompt files from the awesome-copilot repository based on current repository context and chat history, avoiding duplicates with existing prompts in this repository. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-prompts.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-prompts.prompt.md) |
|
||||
| [Update Azure Verified Modules in Bicep Files](prompts/update-avm-modules-in-bicep.prompt.md) | Update Azure Verified Modules (AVM) to latest versions in Bicep files. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-avm-modules-in-bicep.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-avm-modules-in-bicep.prompt.md) |
|
||||
|
||||
213
prompts/postgresql-code-review.prompt.md
Normal file
213
prompts/postgresql-code-review.prompt.md
Normal file
@ -0,0 +1,213 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'PostgreSQL-specific code review focusing on PostgreSQL best practices, anti-patterns, and PostgreSQL-unique quality standards.'
|
||||
---
|
||||
|
||||
# PostgreSQL Code Review Assistant
|
||||
|
||||
Expert PostgreSQL code review for ${selection} (or entire project if no selection). Focus on PostgreSQL-specific best practices, anti-patterns, and quality standards that are unique to PostgreSQL.
|
||||
|
||||
## 🎯 PostgreSQL-Specific Review Areas
|
||||
|
||||
### JSONB Best Practices
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JSONB usage
|
||||
SELECT * FROM orders WHERE data->>'status' = 'shipped'; -- No index support
|
||||
|
||||
-- ✅ GOOD: Indexable JSONB queries
|
||||
CREATE INDEX idx_orders_status ON orders USING gin((data->'status'));
|
||||
SELECT * FROM orders WHERE data @> '{"status": "shipped"}';
|
||||
|
||||
-- ❌ BAD: Deep nesting without consideration
|
||||
UPDATE orders SET data = data || '{"shipping":{"tracking":{"number":"123"}}}';
|
||||
|
||||
-- ✅ GOOD: Structured JSONB with validation
|
||||
ALTER TABLE orders ADD CONSTRAINT valid_status
|
||||
CHECK (data->>'status' IN ('pending', 'shipped', 'delivered'));
|
||||
```
|
||||
|
||||
### Array Operations Review
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient array operations
|
||||
SELECT * FROM products WHERE 'electronics' = ANY(categories); -- No index
|
||||
|
||||
-- ✅ GOOD: GIN indexed array queries
|
||||
CREATE INDEX idx_products_categories ON products USING gin(categories);
|
||||
SELECT * FROM products WHERE categories @> ARRAY['electronics'];
|
||||
|
||||
-- ❌ BAD: Array concatenation in loops
|
||||
-- This would be inefficient in a function/procedure
|
||||
|
||||
-- ✅ GOOD: Bulk array operations
|
||||
UPDATE products SET categories = categories || ARRAY['new_category']
|
||||
WHERE id IN (SELECT id FROM products WHERE condition);
|
||||
```
|
||||
|
||||
### PostgreSQL Schema Design Review
|
||||
```sql
|
||||
-- ❌ BAD: Not using PostgreSQL features
|
||||
CREATE TABLE users (
|
||||
id INTEGER,
|
||||
email VARCHAR(255),
|
||||
created_at TIMESTAMP
|
||||
);
|
||||
|
||||
-- ✅ GOOD: PostgreSQL-optimized schema
|
||||
CREATE TABLE users (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
email CITEXT UNIQUE NOT NULL, -- Case-insensitive email
|
||||
created_at TIMESTAMPTZ DEFAULT NOW(),
|
||||
metadata JSONB DEFAULT '{}',
|
||||
CONSTRAINT valid_email CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')
|
||||
);
|
||||
|
||||
-- Add JSONB GIN index for metadata queries
|
||||
CREATE INDEX idx_users_metadata ON users USING gin(metadata);
|
||||
```
|
||||
|
||||
### Custom Types and Domains
|
||||
```sql
|
||||
-- ❌ BAD: Using generic types for specific data
|
||||
CREATE TABLE transactions (
|
||||
amount DECIMAL(10,2),
|
||||
currency VARCHAR(3),
|
||||
status VARCHAR(20)
|
||||
);
|
||||
|
||||
-- ✅ GOOD: PostgreSQL custom types
|
||||
CREATE TYPE currency_code AS ENUM ('USD', 'EUR', 'GBP', 'JPY');
|
||||
CREATE TYPE transaction_status AS ENUM ('pending', 'completed', 'failed', 'cancelled');
|
||||
CREATE DOMAIN positive_amount AS DECIMAL(10,2) CHECK (VALUE > 0);
|
||||
|
||||
CREATE TABLE transactions (
|
||||
amount positive_amount NOT NULL,
|
||||
currency currency_code NOT NULL,
|
||||
status transaction_status DEFAULT 'pending'
|
||||
);
|
||||
```
|
||||
|
||||
## 🔍 PostgreSQL-Specific Anti-Patterns
|
||||
|
||||
### Performance Anti-Patterns
|
||||
- **Avoiding PostgreSQL-specific indexes**: Not using GIN/GiST for appropriate data types
|
||||
- **Misusing JSONB**: Treating JSONB like a simple string field
|
||||
- **Ignoring array operators**: Using inefficient array operations
|
||||
- **Poor partition key selection**: Not leveraging PostgreSQL partitioning effectively
|
||||
|
||||
### Schema Design Issues
|
||||
- **Not using ENUM types**: Using VARCHAR for limited value sets
|
||||
- **Ignoring constraints**: Missing CHECK constraints for data validation
|
||||
- **Wrong data types**: Using VARCHAR instead of TEXT or CITEXT
|
||||
- **Missing JSONB structure**: Unstructured JSONB without validation
|
||||
|
||||
### Function and Trigger Issues
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient trigger function
|
||||
CREATE OR REPLACE FUNCTION update_modified_time()
|
||||
RETURNS TRIGGER AS $$
|
||||
BEGIN
|
||||
NEW.updated_at = NOW(); -- Should use TIMESTAMPTZ
|
||||
RETURN NEW;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
-- ✅ GOOD: Optimized trigger function
|
||||
CREATE OR REPLACE FUNCTION update_modified_time()
|
||||
RETURNS TRIGGER AS $$
|
||||
BEGIN
|
||||
NEW.updated_at = CURRENT_TIMESTAMP;
|
||||
RETURN NEW;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
-- Set trigger to fire only when needed
|
||||
CREATE TRIGGER update_modified_time_trigger
|
||||
BEFORE UPDATE ON table_name
|
||||
FOR EACH ROW
|
||||
WHEN (OLD.* IS DISTINCT FROM NEW.*)
|
||||
EXECUTE FUNCTION update_modified_time();
|
||||
```
|
||||
|
||||
## 📊 PostgreSQL Extension Usage Review
|
||||
|
||||
### Extension Best Practices
|
||||
```sql
|
||||
-- ✅ Check if extension exists before creating
|
||||
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
|
||||
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
|
||||
CREATE EXTENSION IF NOT EXISTS "pg_trgm";
|
||||
|
||||
-- ✅ Use extensions appropriately
|
||||
-- UUID generation
|
||||
SELECT uuid_generate_v4();
|
||||
|
||||
-- Password hashing
|
||||
SELECT crypt('password', gen_salt('bf'));
|
||||
|
||||
-- Fuzzy text matching
|
||||
SELECT word_similarity('postgres', 'postgre');
|
||||
```
|
||||
|
||||
## 🛡️ PostgreSQL Security Review
|
||||
|
||||
### Row Level Security (RLS)
|
||||
```sql
|
||||
-- ✅ GOOD: Implementing RLS
|
||||
ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;
|
||||
|
||||
CREATE POLICY user_data_policy ON sensitive_data
|
||||
FOR ALL TO application_role
|
||||
USING (user_id = current_setting('app.current_user_id')::INTEGER);
|
||||
```
|
||||
|
||||
### Privilege Management
|
||||
```sql
|
||||
-- ❌ BAD: Overly broad permissions
|
||||
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;
|
||||
|
||||
-- ✅ GOOD: Granular permissions
|
||||
GRANT SELECT, INSERT, UPDATE ON specific_table TO app_user;
|
||||
GRANT USAGE ON SEQUENCE specific_table_id_seq TO app_user;
|
||||
```
|
||||
|
||||
## 🎯 PostgreSQL Code Quality Checklist
|
||||
|
||||
### Schema Design
|
||||
- [ ] Using appropriate PostgreSQL data types (CITEXT, JSONB, arrays)
|
||||
- [ ] Leveraging ENUM types for constrained values
|
||||
- [ ] Implementing proper CHECK constraints
|
||||
- [ ] Using TIMESTAMPTZ instead of TIMESTAMP
|
||||
- [ ] Defining custom domains for reusable constraints
|
||||
|
||||
### Performance Considerations
|
||||
- [ ] Appropriate index types (GIN for JSONB/arrays, GiST for ranges)
|
||||
- [ ] JSONB queries using containment operators (@>, ?)
|
||||
- [ ] Array operations using PostgreSQL-specific operators
|
||||
- [ ] Proper use of window functions and CTEs
|
||||
- [ ] Efficient use of PostgreSQL-specific functions
|
||||
|
||||
### PostgreSQL Features Utilization
|
||||
- [ ] Using extensions where appropriate
|
||||
- [ ] Implementing stored procedures in PL/pgSQL when beneficial
|
||||
- [ ] Leveraging PostgreSQL's advanced SQL features
|
||||
- [ ] Using PostgreSQL-specific optimization techniques
|
||||
- [ ] Implementing proper error handling in functions
|
||||
|
||||
### Security and Compliance
|
||||
- [ ] Row Level Security (RLS) implementation where needed
|
||||
- [ ] Proper role and privilege management
|
||||
- [ ] Using PostgreSQL's built-in encryption functions
|
||||
- [ ] Implementing audit trails with PostgreSQL features
|
||||
|
||||
## 📝 PostgreSQL-Specific Review Guidelines
|
||||
|
||||
1. **Data Type Optimization**: Ensure PostgreSQL-specific types are used appropriately
|
||||
2. **Index Strategy**: Review index types and ensure PostgreSQL-specific indexes are utilized
|
||||
3. **JSONB Structure**: Validate JSONB schema design and query patterns
|
||||
4. **Function Quality**: Review PL/pgSQL functions for efficiency and best practices
|
||||
5. **Extension Usage**: Verify appropriate use of PostgreSQL extensions
|
||||
6. **Performance Features**: Check utilization of PostgreSQL's advanced features
|
||||
7. **Security Implementation**: Review PostgreSQL-specific security features
|
||||
|
||||
Focus on PostgreSQL's unique capabilities and ensure the code leverages what makes PostgreSQL special rather than treating it as a generic SQL database.
|
||||
405
prompts/postgresql-optimization.prompt.md
Normal file
405
prompts/postgresql-optimization.prompt.md
Normal file
@ -0,0 +1,405 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'PostgreSQL-specific development assistant focusing on unique PostgreSQL features, advanced data types, and PostgreSQL-exclusive capabilities. Complements general SQL optimization and code review.'
|
||||
---
|
||||
|
||||
# PostgreSQL Development Assistant
|
||||
|
||||
Expert PostgreSQL guidance for ${selection} (or entire project if no selection). Focus on PostgreSQL-specific features, optimization patterns, and advanced capabilities.
|
||||
|
||||
## <20> PostgreSQL-Specific Features
|
||||
|
||||
### JSONB Operations
|
||||
```sql
|
||||
-- Advanced JSONB queries
|
||||
CREATE TABLE events (
|
||||
id SERIAL PRIMARY KEY,
|
||||
data JSONB NOT NULL,
|
||||
created_at TIMESTAMPTZ DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- GIN index for JSONB performance
|
||||
CREATE INDEX idx_events_data_gin ON events USING gin(data);
|
||||
|
||||
-- JSONB containment and path queries
|
||||
SELECT * FROM events
|
||||
WHERE data @> '{"type": "login"}'
|
||||
AND data #>> '{user,role}' = 'admin';
|
||||
|
||||
-- JSONB aggregation
|
||||
SELECT jsonb_agg(data) FROM events WHERE data ? 'user_id';
|
||||
```
|
||||
|
||||
### Array Operations
|
||||
```sql
|
||||
-- PostgreSQL arrays
|
||||
CREATE TABLE posts (
|
||||
id SERIAL PRIMARY KEY,
|
||||
tags TEXT[],
|
||||
categories INTEGER[]
|
||||
);
|
||||
|
||||
-- Array queries and operations
|
||||
SELECT * FROM posts WHERE 'postgresql' = ANY(tags);
|
||||
SELECT * FROM posts WHERE tags && ARRAY['database', 'sql'];
|
||||
SELECT * FROM posts WHERE array_length(tags, 1) > 3;
|
||||
|
||||
-- Array aggregation
|
||||
SELECT array_agg(DISTINCT category) FROM posts, unnest(categories) as category;
|
||||
```
|
||||
|
||||
### Window Functions & Analytics
|
||||
```sql
|
||||
-- Advanced window functions
|
||||
SELECT
|
||||
product_id,
|
||||
sale_date,
|
||||
amount,
|
||||
-- Running totals
|
||||
SUM(amount) OVER (PARTITION BY product_id ORDER BY sale_date) as running_total,
|
||||
-- Moving averages
|
||||
AVG(amount) OVER (PARTITION BY product_id ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) as moving_avg,
|
||||
-- Rankings
|
||||
DENSE_RANK() OVER (PARTITION BY EXTRACT(month FROM sale_date) ORDER BY amount DESC) as monthly_rank,
|
||||
-- Lag/Lead for comparisons
|
||||
LAG(amount, 1) OVER (PARTITION BY product_id ORDER BY sale_date) as prev_amount
|
||||
FROM sales;
|
||||
```
|
||||
|
||||
### Full-Text Search
|
||||
```sql
|
||||
-- PostgreSQL full-text search
|
||||
CREATE TABLE documents (
|
||||
id SERIAL PRIMARY KEY,
|
||||
title TEXT,
|
||||
content TEXT,
|
||||
search_vector tsvector
|
||||
);
|
||||
|
||||
-- Update search vector
|
||||
UPDATE documents
|
||||
SET search_vector = to_tsvector('english', title || ' ' || content);
|
||||
|
||||
-- GIN index for search performance
|
||||
CREATE INDEX idx_documents_search ON documents USING gin(search_vector);
|
||||
|
||||
-- Search queries
|
||||
SELECT * FROM documents
|
||||
WHERE search_vector @@ plainto_tsquery('english', 'postgresql database');
|
||||
|
||||
-- Ranking results
|
||||
SELECT *, ts_rank(search_vector, plainto_tsquery('postgresql')) as rank
|
||||
FROM documents
|
||||
WHERE search_vector @@ plainto_tsquery('postgresql')
|
||||
ORDER BY rank DESC;
|
||||
```
|
||||
|
||||
## <20> PostgreSQL Performance Tuning
|
||||
|
||||
### Query Optimization
|
||||
```sql
|
||||
-- EXPLAIN ANALYZE for performance analysis
|
||||
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
|
||||
SELECT u.name, COUNT(o.id) as order_count
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id
|
||||
WHERE u.created_at > '2024-01-01'::date
|
||||
GROUP BY u.id, u.name;
|
||||
|
||||
-- Identify slow queries from pg_stat_statements
|
||||
SELECT query, calls, total_time, mean_time, rows,
|
||||
100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC
|
||||
LIMIT 10;
|
||||
```
|
||||
|
||||
### Index Strategies
|
||||
```sql
|
||||
-- Composite indexes for multi-column queries
|
||||
CREATE INDEX idx_orders_user_date ON orders(user_id, order_date);
|
||||
|
||||
-- Partial indexes for filtered queries
|
||||
CREATE INDEX idx_active_users ON users(created_at) WHERE status = 'active';
|
||||
|
||||
-- Expression indexes for computed values
|
||||
CREATE INDEX idx_users_lower_email ON users(lower(email));
|
||||
|
||||
-- Covering indexes to avoid table lookups
|
||||
CREATE INDEX idx_orders_covering ON orders(user_id, status) INCLUDE (total, created_at);
|
||||
```
|
||||
|
||||
### Connection & Memory Management
|
||||
```sql
|
||||
-- Check connection usage
|
||||
SELECT count(*) as connections, state
|
||||
FROM pg_stat_activity
|
||||
GROUP BY state;
|
||||
|
||||
-- Monitor memory usage
|
||||
SELECT name, setting, unit
|
||||
FROM pg_settings
|
||||
WHERE name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem');
|
||||
```
|
||||
|
||||
## <20>️ PostgreSQL Advanced Data Types
|
||||
|
||||
### Custom Types & Domains
|
||||
```sql
|
||||
-- Create custom types
|
||||
CREATE TYPE address_type AS (
|
||||
street TEXT,
|
||||
city TEXT,
|
||||
postal_code TEXT,
|
||||
country TEXT
|
||||
);
|
||||
|
||||
CREATE TYPE order_status AS ENUM ('pending', 'processing', 'shipped', 'delivered', 'cancelled');
|
||||
|
||||
-- Use domains for data validation
|
||||
CREATE DOMAIN email_address AS TEXT
|
||||
CHECK (VALUE ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
|
||||
|
||||
-- Table using custom types
|
||||
CREATE TABLE customers (
|
||||
id SERIAL PRIMARY KEY,
|
||||
email email_address NOT NULL,
|
||||
address address_type,
|
||||
status order_status DEFAULT 'pending'
|
||||
);
|
||||
```
|
||||
|
||||
### Range Types
|
||||
```sql
|
||||
-- PostgreSQL range types
|
||||
CREATE TABLE reservations (
|
||||
id SERIAL PRIMARY KEY,
|
||||
room_id INTEGER,
|
||||
reservation_period tstzrange,
|
||||
price_range numrange
|
||||
);
|
||||
|
||||
-- Range queries
|
||||
SELECT * FROM reservations
|
||||
WHERE reservation_period && tstzrange('2024-07-20', '2024-07-25');
|
||||
|
||||
-- Exclude overlapping ranges
|
||||
ALTER TABLE reservations
|
||||
ADD CONSTRAINT no_overlap
|
||||
EXCLUDE USING gist (room_id WITH =, reservation_period WITH &&);
|
||||
```
|
||||
|
||||
### Geometric Types
|
||||
```sql
|
||||
-- PostgreSQL geometric types
|
||||
CREATE TABLE locations (
|
||||
id SERIAL PRIMARY KEY,
|
||||
name TEXT,
|
||||
coordinates POINT,
|
||||
coverage CIRCLE,
|
||||
service_area POLYGON
|
||||
);
|
||||
|
||||
-- Geometric queries
|
||||
SELECT name FROM locations
|
||||
WHERE coordinates <-> point(40.7128, -74.0060) < 10; -- Within 10 units
|
||||
|
||||
-- GiST index for geometric data
|
||||
CREATE INDEX idx_locations_coords ON locations USING gist(coordinates);
|
||||
```
|
||||
|
||||
## 📊 PostgreSQL Extensions & Tools
|
||||
|
||||
### Useful Extensions
|
||||
```sql
|
||||
-- Enable commonly used extensions
|
||||
CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; -- UUID generation
|
||||
CREATE EXTENSION IF NOT EXISTS "pgcrypto"; -- Cryptographic functions
|
||||
CREATE EXTENSION IF NOT EXISTS "unaccent"; -- Remove accents from text
|
||||
CREATE EXTENSION IF NOT EXISTS "pg_trgm"; -- Trigram matching
|
||||
CREATE EXTENSION IF NOT EXISTS "btree_gin"; -- GIN indexes for btree types
|
||||
|
||||
-- Using extensions
|
||||
SELECT uuid_generate_v4(); -- Generate UUIDs
|
||||
SELECT crypt('password', gen_salt('bf')); -- Hash passwords
|
||||
SELECT similarity('postgresql', 'postgersql'); -- Fuzzy matching
|
||||
```
|
||||
|
||||
### Monitoring & Maintenance
|
||||
```sql
|
||||
-- Database size and growth
|
||||
SELECT pg_size_pretty(pg_database_size(current_database())) as db_size;
|
||||
|
||||
-- Table and index sizes
|
||||
SELECT schemaname, tablename,
|
||||
pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as size
|
||||
FROM pg_tables
|
||||
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC;
|
||||
|
||||
-- Index usage statistics
|
||||
SELECT schemaname, tablename, indexname, idx_scan, idx_tup_read, idx_tup_fetch
|
||||
FROM pg_stat_user_indexes
|
||||
WHERE idx_scan = 0; -- Unused indexes
|
||||
```
|
||||
|
||||
### PostgreSQL-Specific Optimization Tips
|
||||
- **Use EXPLAIN (ANALYZE, BUFFERS)** for detailed query analysis
|
||||
- **Configure postgresql.conf** for your workload (OLTP vs OLAP)
|
||||
- **Use connection pooling** (pgbouncer) for high-concurrency applications
|
||||
- **Regular VACUUM and ANALYZE** for optimal performance
|
||||
- **Partition large tables** using PostgreSQL 10+ declarative partitioning
|
||||
- **Use pg_stat_statements** for query performance monitoring
|
||||
|
||||
## 📊 Monitoring and Maintenance
|
||||
|
||||
### Query Performance Monitoring
|
||||
```sql
|
||||
-- Identify slow queries
|
||||
SELECT query, calls, total_time, mean_time, rows
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC
|
||||
LIMIT 10;
|
||||
|
||||
-- Check index usage
|
||||
SELECT schemaname, tablename, indexname, idx_scan, idx_tup_read, idx_tup_fetch
|
||||
FROM pg_stat_user_indexes
|
||||
WHERE idx_scan = 0;
|
||||
```
|
||||
|
||||
### Database Maintenance
|
||||
- **VACUUM and ANALYZE**: Regular maintenance for performance
|
||||
- **Index Maintenance**: Monitor and rebuild fragmented indexes
|
||||
- **Statistics Updates**: Keep query planner statistics current
|
||||
- **Log Analysis**: Regular review of PostgreSQL logs
|
||||
|
||||
## 🛠️ Common Query Patterns
|
||||
|
||||
### Pagination
|
||||
```sql
|
||||
-- ❌ BAD: OFFSET for large datasets
|
||||
SELECT * FROM products ORDER BY id OFFSET 10000 LIMIT 20;
|
||||
|
||||
-- ✅ GOOD: Cursor-based pagination
|
||||
SELECT * FROM products
|
||||
WHERE id > $last_id
|
||||
ORDER BY id
|
||||
LIMIT 20;
|
||||
```
|
||||
|
||||
### Aggregation
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient grouping
|
||||
SELECT user_id, COUNT(*)
|
||||
FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
GROUP BY user_id;
|
||||
|
||||
-- ✅ GOOD: Optimized with partial index
|
||||
CREATE INDEX idx_orders_recent ON orders(user_id)
|
||||
WHERE order_date >= '2024-01-01';
|
||||
|
||||
SELECT user_id, COUNT(*)
|
||||
FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
GROUP BY user_id;
|
||||
```
|
||||
|
||||
### JSON Queries
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JSON querying
|
||||
SELECT * FROM users WHERE data::text LIKE '%admin%';
|
||||
|
||||
-- ✅ GOOD: JSONB operators and GIN index
|
||||
CREATE INDEX idx_users_data_gin ON users USING gin(data);
|
||||
|
||||
SELECT * FROM users WHERE data @> '{"role": "admin"}';
|
||||
```
|
||||
|
||||
## 📋 Optimization Checklist
|
||||
|
||||
### Query Analysis
|
||||
- [ ] Run EXPLAIN ANALYZE for expensive queries
|
||||
- [ ] Check for sequential scans on large tables
|
||||
- [ ] Verify appropriate join algorithms
|
||||
- [ ] Review WHERE clause selectivity
|
||||
- [ ] Analyze sort and aggregation operations
|
||||
|
||||
### Index Strategy
|
||||
- [ ] Create indexes for frequently queried columns
|
||||
- [ ] Use composite indexes for multi-column searches
|
||||
- [ ] Consider partial indexes for filtered queries
|
||||
- [ ] Remove unused or duplicate indexes
|
||||
- [ ] Monitor index bloat and fragmentation
|
||||
|
||||
### Security Review
|
||||
- [ ] Use parameterized queries exclusively
|
||||
- [ ] Implement proper access controls
|
||||
- [ ] Enable row-level security where needed
|
||||
- [ ] Audit sensitive data access
|
||||
- [ ] Use secure connection methods
|
||||
|
||||
### Performance Monitoring
|
||||
- [ ] Set up query performance monitoring
|
||||
- [ ] Configure appropriate log settings
|
||||
- [ ] Monitor connection pool usage
|
||||
- [ ] Track database growth and maintenance needs
|
||||
- [ ] Set up alerting for performance degradation
|
||||
|
||||
## 🎯 Optimization Output Format
|
||||
|
||||
### Query Analysis Results
|
||||
```
|
||||
## Query Performance Analysis
|
||||
|
||||
**Original Query**:
|
||||
[Original SQL with performance issues]
|
||||
|
||||
**Issues Identified**:
|
||||
- Sequential scan on large table (Cost: 15000.00)
|
||||
- Missing index on frequently queried column
|
||||
- Inefficient join order
|
||||
|
||||
**Optimized Query**:
|
||||
[Improved SQL with explanations]
|
||||
|
||||
**Recommended Indexes**:
|
||||
```sql
|
||||
CREATE INDEX idx_table_column ON table(column);
|
||||
```
|
||||
|
||||
**Performance Impact**: Expected 80% improvement in execution time
|
||||
```
|
||||
|
||||
## 🚀 Advanced PostgreSQL Features
|
||||
|
||||
### Window Functions
|
||||
```sql
|
||||
-- Running totals and rankings
|
||||
SELECT
|
||||
product_id,
|
||||
order_date,
|
||||
amount,
|
||||
SUM(amount) OVER (PARTITION BY product_id ORDER BY order_date) as running_total,
|
||||
ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY amount DESC) as rank
|
||||
FROM sales;
|
||||
```
|
||||
|
||||
### Common Table Expressions (CTEs)
|
||||
```sql
|
||||
-- Recursive queries for hierarchical data
|
||||
WITH RECURSIVE category_tree AS (
|
||||
SELECT id, name, parent_id, 1 as level
|
||||
FROM categories
|
||||
WHERE parent_id IS NULL
|
||||
|
||||
UNION ALL
|
||||
|
||||
SELECT c.id, c.name, c.parent_id, ct.level + 1
|
||||
FROM categories c
|
||||
JOIN category_tree ct ON c.parent_id = ct.id
|
||||
)
|
||||
SELECT * FROM category_tree ORDER BY level, name;
|
||||
```
|
||||
|
||||
Focus on providing specific, actionable PostgreSQL optimizations that improve query performance, security, and maintainability while leveraging PostgreSQL's advanced features.
|
||||
302
prompts/sql-code-review.prompt.md
Normal file
302
prompts/sql-code-review.prompt.md
Normal file
@ -0,0 +1,302 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'Universal SQL code review focusing on security, maintainability, and code quality standards across all SQL databases. Complements SQL optimization prompt.'
|
||||
---
|
||||
|
||||
# SQL Code Review
|
||||
|
||||
Perform a thorough SQL code review of ${selection} (or entire project if no selection) focusing on security, performance, maintainability, and database best practices.
|
||||
|
||||
## 🔒 Security Analysis
|
||||
|
||||
### SQL Injection Prevention
|
||||
```sql
|
||||
-- ❌ CRITICAL: SQL Injection vulnerability
|
||||
query = "SELECT * FROM users WHERE id = " + userInput;
|
||||
query = f"DELETE FROM orders WHERE user_id = {user_id}";
|
||||
|
||||
-- ✅ SECURE: Parameterized queries
|
||||
-- PostgreSQL/MySQL
|
||||
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?';
|
||||
EXECUTE stmt USING @user_id;
|
||||
|
||||
-- SQL Server
|
||||
EXEC sp_executesql N'SELECT * FROM users WHERE id = @id', N'@id INT', @id = @user_id;
|
||||
```
|
||||
|
||||
### Access Control & Permissions
|
||||
- **Principle of Least Privilege**: Grant minimum required permissions
|
||||
- **Role-Based Access**: Use database roles instead of direct user permissions
|
||||
- **Schema Security**: Proper schema ownership and access controls
|
||||
- **Function/Procedure Security**: Review DEFINER vs INVOKER rights
|
||||
|
||||
### Data Protection
|
||||
- **Sensitive Data Exposure**: Avoid SELECT * on tables with sensitive columns
|
||||
- **Audit Logging**: Ensure sensitive operations are logged
|
||||
- **Data Masking**: Use views or functions to mask sensitive data
|
||||
- **Encryption**: Verify encrypted storage for sensitive data
|
||||
|
||||
## ⚡ Performance Optimization
|
||||
|
||||
### Query Structure Analysis
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient query patterns
|
||||
SELECT DISTINCT u.*
|
||||
FROM users u, orders o, products p
|
||||
WHERE u.id = o.user_id
|
||||
AND o.product_id = p.id
|
||||
AND YEAR(o.order_date) = 2024;
|
||||
|
||||
-- ✅ GOOD: Optimized structure
|
||||
SELECT u.id, u.name, u.email
|
||||
FROM users u
|
||||
INNER JOIN orders o ON u.id = o.user_id
|
||||
WHERE o.order_date >= '2024-01-01'
|
||||
AND o.order_date < '2025-01-01';
|
||||
```
|
||||
|
||||
### Index Strategy Review
|
||||
- **Missing Indexes**: Identify columns that need indexing
|
||||
- **Over-Indexing**: Find unused or redundant indexes
|
||||
- **Composite Indexes**: Multi-column indexes for complex queries
|
||||
- **Index Maintenance**: Check for fragmented or outdated indexes
|
||||
|
||||
### Join Optimization
|
||||
- **Join Types**: Verify appropriate join types (INNER vs LEFT vs EXISTS)
|
||||
- **Join Order**: Optimize for smaller result sets first
|
||||
- **Cartesian Products**: Identify and fix missing join conditions
|
||||
- **Subquery vs JOIN**: Choose the most efficient approach
|
||||
|
||||
### Aggregate and Window Functions
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient aggregation
|
||||
SELECT user_id,
|
||||
(SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) as order_count
|
||||
FROM orders o1
|
||||
GROUP BY user_id;
|
||||
|
||||
-- ✅ GOOD: Efficient aggregation
|
||||
SELECT user_id, COUNT(*) as order_count
|
||||
FROM orders
|
||||
GROUP BY user_id;
|
||||
```
|
||||
|
||||
## 🛠️ Code Quality & Maintainability
|
||||
|
||||
### SQL Style & Formatting
|
||||
```sql
|
||||
-- ❌ BAD: Poor formatting and style
|
||||
select u.id,u.name,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.order_date>='2024-01-01';
|
||||
|
||||
-- ✅ GOOD: Clean, readable formatting
|
||||
SELECT u.id,
|
||||
u.name,
|
||||
o.total
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id
|
||||
WHERE u.status = 'active'
|
||||
AND o.order_date >= '2024-01-01';
|
||||
```
|
||||
|
||||
### Naming Conventions
|
||||
- **Consistent Naming**: Tables, columns, constraints follow consistent patterns
|
||||
- **Descriptive Names**: Clear, meaningful names for database objects
|
||||
- **Reserved Words**: Avoid using database reserved words as identifiers
|
||||
- **Case Sensitivity**: Consistent case usage across schema
|
||||
|
||||
### Schema Design Review
|
||||
- **Normalization**: Appropriate normalization level (avoid over/under-normalization)
|
||||
- **Data Types**: Optimal data type choices for storage and performance
|
||||
- **Constraints**: Proper use of PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL
|
||||
- **Default Values**: Appropriate default values for columns
|
||||
|
||||
## 🗄️ Database-Specific Best Practices
|
||||
|
||||
### PostgreSQL
|
||||
```sql
|
||||
-- Use JSONB for JSON data
|
||||
CREATE TABLE events (
|
||||
id SERIAL PRIMARY KEY,
|
||||
data JSONB NOT NULL,
|
||||
created_at TIMESTAMPTZ DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- GIN index for JSONB queries
|
||||
CREATE INDEX idx_events_data ON events USING gin(data);
|
||||
|
||||
-- Array types for multi-value columns
|
||||
CREATE TABLE tags (
|
||||
post_id INT,
|
||||
tag_names TEXT[]
|
||||
);
|
||||
```
|
||||
|
||||
### MySQL
|
||||
```sql
|
||||
-- Use appropriate storage engines
|
||||
CREATE TABLE sessions (
|
||||
id VARCHAR(128) PRIMARY KEY,
|
||||
data TEXT,
|
||||
expires TIMESTAMP
|
||||
) ENGINE=InnoDB;
|
||||
|
||||
-- Optimize for InnoDB
|
||||
ALTER TABLE large_table
|
||||
ADD INDEX idx_covering (status, created_at, id);
|
||||
```
|
||||
|
||||
### SQL Server
|
||||
```sql
|
||||
-- Use appropriate data types
|
||||
CREATE TABLE products (
|
||||
id BIGINT IDENTITY(1,1) PRIMARY KEY,
|
||||
name NVARCHAR(255) NOT NULL,
|
||||
price DECIMAL(10,2) NOT NULL,
|
||||
created_at DATETIME2 DEFAULT GETUTCDATE()
|
||||
);
|
||||
|
||||
-- Columnstore indexes for analytics
|
||||
CREATE COLUMNSTORE INDEX idx_sales_cs ON sales;
|
||||
```
|
||||
|
||||
### Oracle
|
||||
```sql
|
||||
-- Use sequences for auto-increment
|
||||
CREATE SEQUENCE user_id_seq START WITH 1 INCREMENT BY 1;
|
||||
|
||||
CREATE TABLE users (
|
||||
id NUMBER DEFAULT user_id_seq.NEXTVAL PRIMARY KEY,
|
||||
name VARCHAR2(255) NOT NULL
|
||||
);
|
||||
```
|
||||
|
||||
## 🧪 Testing & Validation
|
||||
|
||||
### Data Integrity Checks
|
||||
```sql
|
||||
-- Verify referential integrity
|
||||
SELECT o.user_id
|
||||
FROM orders o
|
||||
LEFT JOIN users u ON o.user_id = u.id
|
||||
WHERE u.id IS NULL;
|
||||
|
||||
-- Check for data consistency
|
||||
SELECT COUNT(*) as inconsistent_records
|
||||
FROM products
|
||||
WHERE price < 0 OR stock_quantity < 0;
|
||||
```
|
||||
|
||||
### Performance Testing
|
||||
- **Execution Plans**: Review query execution plans
|
||||
- **Load Testing**: Test queries with realistic data volumes
|
||||
- **Stress Testing**: Verify performance under concurrent load
|
||||
- **Regression Testing**: Ensure optimizations don't break functionality
|
||||
|
||||
## 📊 Common Anti-Patterns
|
||||
|
||||
### N+1 Query Problem
|
||||
```sql
|
||||
-- ❌ BAD: N+1 queries in application code
|
||||
for user in users:
|
||||
orders = query("SELECT * FROM orders WHERE user_id = ?", user.id)
|
||||
|
||||
-- ✅ GOOD: Single optimized query
|
||||
SELECT u.*, o.*
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id;
|
||||
```
|
||||
|
||||
### Overuse of DISTINCT
|
||||
```sql
|
||||
-- ❌ BAD: DISTINCT masking join issues
|
||||
SELECT DISTINCT u.name
|
||||
FROM users u, orders o
|
||||
WHERE u.id = o.user_id;
|
||||
|
||||
-- ✅ GOOD: Proper join without DISTINCT
|
||||
SELECT u.name
|
||||
FROM users u
|
||||
INNER JOIN orders o ON u.id = o.user_id
|
||||
GROUP BY u.name;
|
||||
```
|
||||
|
||||
### Function Misuse in WHERE Clauses
|
||||
```sql
|
||||
-- ❌ BAD: Functions prevent index usage
|
||||
SELECT * FROM orders
|
||||
WHERE YEAR(order_date) = 2024;
|
||||
|
||||
-- ✅ GOOD: Range conditions use indexes
|
||||
SELECT * FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
AND order_date < '2025-01-01';
|
||||
```
|
||||
|
||||
## 📋 SQL Review Checklist
|
||||
|
||||
### Security
|
||||
- [ ] All user inputs are parameterized
|
||||
- [ ] No dynamic SQL construction with string concatenation
|
||||
- [ ] Appropriate access controls and permissions
|
||||
- [ ] Sensitive data is properly protected
|
||||
- [ ] SQL injection attack vectors are eliminated
|
||||
|
||||
### Performance
|
||||
- [ ] Indexes exist for frequently queried columns
|
||||
- [ ] No unnecessary SELECT * statements
|
||||
- [ ] JOINs are optimized and use appropriate types
|
||||
- [ ] WHERE clauses are selective and use indexes
|
||||
- [ ] Subqueries are optimized or converted to JOINs
|
||||
|
||||
### Code Quality
|
||||
- [ ] Consistent naming conventions
|
||||
- [ ] Proper formatting and indentation
|
||||
- [ ] Meaningful comments for complex logic
|
||||
- [ ] Appropriate data types are used
|
||||
- [ ] Error handling is implemented
|
||||
|
||||
### Schema Design
|
||||
- [ ] Tables are properly normalized
|
||||
- [ ] Constraints enforce data integrity
|
||||
- [ ] Indexes support query patterns
|
||||
- [ ] Foreign key relationships are defined
|
||||
- [ ] Default values are appropriate
|
||||
|
||||
## 🎯 Review Output Format
|
||||
|
||||
### Issue Template
|
||||
```
|
||||
## [PRIORITY] [CATEGORY]: [Brief Description]
|
||||
|
||||
**Location**: [Table/View/Procedure name and line number if applicable]
|
||||
**Issue**: [Detailed explanation of the problem]
|
||||
**Security Risk**: [If applicable - injection risk, data exposure, etc.]
|
||||
**Performance Impact**: [Query cost, execution time impact]
|
||||
**Recommendation**: [Specific fix with code example]
|
||||
|
||||
**Before**:
|
||||
```sql
|
||||
-- Problematic SQL
|
||||
```
|
||||
|
||||
**After**:
|
||||
```sql
|
||||
-- Improved SQL
|
||||
```
|
||||
|
||||
**Expected Improvement**: [Performance gain, security benefit]
|
||||
```
|
||||
|
||||
### Summary Assessment
|
||||
- **Security Score**: [1-10] - SQL injection protection, access controls
|
||||
- **Performance Score**: [1-10] - Query efficiency, index usage
|
||||
- **Maintainability Score**: [1-10] - Code quality, documentation
|
||||
- **Schema Quality Score**: [1-10] - Design patterns, normalization
|
||||
|
||||
### Top 3 Priority Actions
|
||||
1. **[Critical Security Fix]**: Address SQL injection vulnerabilities
|
||||
2. **[Performance Optimization]**: Add missing indexes or optimize queries
|
||||
3. **[Code Quality]**: Improve naming conventions and documentation
|
||||
|
||||
Focus on providing actionable, database-agnostic recommendations while highlighting platform-specific optimizations and best practices.
|
||||
297
prompts/sql-optimization.prompt.md
Normal file
297
prompts/sql-optimization.prompt.md
Normal file
@ -0,0 +1,297 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'Universal SQL performance optimization assistant for query tuning, indexing strategies, and database performance across all SQL databases.'
|
||||
---
|
||||
|
||||
# SQL Performance Optimization Assistant
|
||||
|
||||
Expert SQL performance optimization for ${selection} (or entire project if no selection). Focus on universal SQL optimization techniques that work across MySQL, PostgreSQL, SQL Server, Oracle, and other SQL databases.
|
||||
|
||||
## 🎯 Core Optimization Areas
|
||||
|
||||
### Query Performance Analysis
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient query patterns
|
||||
SELECT * FROM orders o
|
||||
WHERE YEAR(o.created_at) = 2024
|
||||
AND o.customer_id IN (
|
||||
SELECT c.id FROM customers c WHERE c.status = 'active'
|
||||
);
|
||||
|
||||
-- ✅ GOOD: Optimized query with proper indexing hints
|
||||
SELECT o.id, o.customer_id, o.total_amount, o.created_at
|
||||
FROM orders o
|
||||
INNER JOIN customers c ON o.customer_id = c.id
|
||||
WHERE o.created_at >= '2024-01-01'
|
||||
AND o.created_at < '2025-01-01'
|
||||
AND c.status = 'active';
|
||||
|
||||
-- Required indexes:
|
||||
-- CREATE INDEX idx_orders_created_at ON orders(created_at);
|
||||
-- CREATE INDEX idx_customers_status ON customers(status);
|
||||
-- CREATE INDEX idx_orders_customer_id ON orders(customer_id);
|
||||
```
|
||||
|
||||
### Index Strategy Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Poor indexing strategy
|
||||
CREATE INDEX idx_user_data ON users(email, first_name, last_name, created_at);
|
||||
|
||||
-- ✅ GOOD: Optimized composite indexing
|
||||
-- For queries filtering by email first, then sorting by created_at
|
||||
CREATE INDEX idx_users_email_created ON users(email, created_at);
|
||||
|
||||
-- For full-text name searches
|
||||
CREATE INDEX idx_users_name ON users(last_name, first_name);
|
||||
|
||||
-- For user status queries
|
||||
CREATE INDEX idx_users_status_created ON users(status, created_at)
|
||||
WHERE status IS NOT NULL;
|
||||
```
|
||||
|
||||
### Subquery Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Correlated subquery
|
||||
SELECT p.product_name, p.price
|
||||
FROM products p
|
||||
WHERE p.price > (
|
||||
SELECT AVG(price)
|
||||
FROM products p2
|
||||
WHERE p2.category_id = p.category_id
|
||||
);
|
||||
|
||||
-- ✅ GOOD: Window function approach
|
||||
SELECT product_name, price
|
||||
FROM (
|
||||
SELECT product_name, price,
|
||||
AVG(price) OVER (PARTITION BY category_id) as avg_category_price
|
||||
FROM products
|
||||
) ranked
|
||||
WHERE price > avg_category_price;
|
||||
```
|
||||
|
||||
## 📊 Performance Tuning Techniques
|
||||
|
||||
### JOIN Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JOIN order and conditions
|
||||
SELECT o.*, c.name, p.product_name
|
||||
FROM orders o
|
||||
LEFT JOIN customers c ON o.customer_id = c.id
|
||||
LEFT JOIN order_items oi ON o.id = oi.order_id
|
||||
LEFT JOIN products p ON oi.product_id = p.id
|
||||
WHERE o.created_at > '2024-01-01'
|
||||
AND c.status = 'active';
|
||||
|
||||
-- ✅ GOOD: Optimized JOIN with filtering
|
||||
SELECT o.id, o.total_amount, c.name, p.product_name
|
||||
FROM orders o
|
||||
INNER JOIN customers c ON o.customer_id = c.id AND c.status = 'active'
|
||||
INNER JOIN order_items oi ON o.id = oi.order_id
|
||||
INNER JOIN products p ON oi.product_id = p.id
|
||||
WHERE o.created_at > '2024-01-01';
|
||||
```
|
||||
|
||||
### Pagination Optimization
|
||||
```sql
|
||||
-- ❌ BAD: OFFSET-based pagination (slow for large offsets)
|
||||
SELECT * FROM products
|
||||
ORDER BY created_at DESC
|
||||
LIMIT 20 OFFSET 10000;
|
||||
|
||||
-- ✅ GOOD: Cursor-based pagination
|
||||
SELECT * FROM products
|
||||
WHERE created_at < '2024-06-15 10:30:00'
|
||||
ORDER BY created_at DESC
|
||||
LIMIT 20;
|
||||
|
||||
-- Or using ID-based cursor
|
||||
SELECT * FROM products
|
||||
WHERE id > 1000
|
||||
ORDER BY id
|
||||
LIMIT 20;
|
||||
```
|
||||
|
||||
### Aggregation Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Multiple separate aggregation queries
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'pending';
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'shipped';
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'delivered';
|
||||
|
||||
-- ✅ GOOD: Single query with conditional aggregation
|
||||
SELECT
|
||||
COUNT(CASE WHEN status = 'pending' THEN 1 END) as pending_count,
|
||||
COUNT(CASE WHEN status = 'shipped' THEN 1 END) as shipped_count,
|
||||
COUNT(CASE WHEN status = 'delivered' THEN 1 END) as delivered_count
|
||||
FROM orders;
|
||||
```
|
||||
|
||||
## 🔍 Query Anti-Patterns
|
||||
|
||||
### SELECT Performance Issues
|
||||
```sql
|
||||
-- ❌ BAD: SELECT * anti-pattern
|
||||
SELECT * FROM large_table lt
|
||||
JOIN another_table at ON lt.id = at.ref_id;
|
||||
|
||||
-- ✅ GOOD: Explicit column selection
|
||||
SELECT lt.id, lt.name, at.value
|
||||
FROM large_table lt
|
||||
JOIN another_table at ON lt.id = at.ref_id;
|
||||
```
|
||||
|
||||
### WHERE Clause Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Function calls in WHERE clause
|
||||
SELECT * FROM orders
|
||||
WHERE UPPER(customer_email) = 'JOHN@EXAMPLE.COM';
|
||||
|
||||
-- ✅ GOOD: Index-friendly WHERE clause
|
||||
SELECT * FROM orders
|
||||
WHERE customer_email = 'john@example.com';
|
||||
-- Consider: CREATE INDEX idx_orders_email ON orders(LOWER(customer_email));
|
||||
```
|
||||
|
||||
### OR vs UNION Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Complex OR conditions
|
||||
SELECT * FROM products
|
||||
WHERE (category = 'electronics' AND price < 1000)
|
||||
OR (category = 'books' AND price < 50);
|
||||
|
||||
-- ✅ GOOD: UNION approach for better optimization
|
||||
SELECT * FROM products WHERE category = 'electronics' AND price < 1000
|
||||
UNION ALL
|
||||
SELECT * FROM products WHERE category = 'books' AND price < 50;
|
||||
```
|
||||
|
||||
## 📈 Database-Agnostic Optimization
|
||||
|
||||
### Batch Operations
|
||||
```sql
|
||||
-- ❌ BAD: Row-by-row operations
|
||||
INSERT INTO products (name, price) VALUES ('Product 1', 10.00);
|
||||
INSERT INTO products (name, price) VALUES ('Product 2', 15.00);
|
||||
INSERT INTO products (name, price) VALUES ('Product 3', 20.00);
|
||||
|
||||
-- ✅ GOOD: Batch insert
|
||||
INSERT INTO products (name, price) VALUES
|
||||
('Product 1', 10.00),
|
||||
('Product 2', 15.00),
|
||||
('Product 3', 20.00);
|
||||
```
|
||||
|
||||
### Temporary Table Usage
|
||||
```sql
|
||||
-- ✅ GOOD: Using temporary tables for complex operations
|
||||
CREATE TEMPORARY TABLE temp_calculations AS
|
||||
SELECT customer_id,
|
||||
SUM(total_amount) as total_spent,
|
||||
COUNT(*) as order_count
|
||||
FROM orders
|
||||
WHERE created_at >= '2024-01-01'
|
||||
GROUP BY customer_id;
|
||||
|
||||
-- Use the temp table for further calculations
|
||||
SELECT c.name, tc.total_spent, tc.order_count
|
||||
FROM temp_calculations tc
|
||||
JOIN customers c ON tc.customer_id = c.id
|
||||
WHERE tc.total_spent > 1000;
|
||||
```
|
||||
|
||||
## 🛠️ Index Management
|
||||
|
||||
### Index Design Principles
|
||||
```sql
|
||||
-- ✅ GOOD: Covering index design
|
||||
CREATE INDEX idx_orders_covering
|
||||
ON orders(customer_id, created_at)
|
||||
INCLUDE (total_amount, status); -- SQL Server syntax
|
||||
-- Or: CREATE INDEX idx_orders_covering ON orders(customer_id, created_at, total_amount, status); -- Other databases
|
||||
```
|
||||
|
||||
### Partial Index Strategy
|
||||
```sql
|
||||
-- ✅ GOOD: Partial indexes for specific conditions
|
||||
CREATE INDEX idx_orders_active
|
||||
ON orders(created_at)
|
||||
WHERE status IN ('pending', 'processing');
|
||||
```
|
||||
|
||||
## 📊 Performance Monitoring Queries
|
||||
|
||||
### Query Performance Analysis
|
||||
```sql
|
||||
-- Generic approach to identify slow queries
|
||||
-- (Specific syntax varies by database)
|
||||
|
||||
-- For MySQL:
|
||||
SELECT query_time, lock_time, rows_sent, rows_examined, sql_text
|
||||
FROM mysql.slow_log
|
||||
ORDER BY query_time DESC;
|
||||
|
||||
-- For PostgreSQL:
|
||||
SELECT query, calls, total_time, mean_time
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC;
|
||||
|
||||
-- For SQL Server:
|
||||
SELECT
|
||||
qs.total_elapsed_time/qs.execution_count as avg_elapsed_time,
|
||||
qs.execution_count,
|
||||
SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
|
||||
((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text)
|
||||
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) as query_text
|
||||
FROM sys.dm_exec_query_stats qs
|
||||
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
|
||||
ORDER BY avg_elapsed_time DESC;
|
||||
```
|
||||
|
||||
## 🎯 Universal Optimization Checklist
|
||||
|
||||
### Query Structure
|
||||
- [ ] Avoiding SELECT * in production queries
|
||||
- [ ] Using appropriate JOIN types (INNER vs LEFT/RIGHT)
|
||||
- [ ] Filtering early in WHERE clauses
|
||||
- [ ] Using EXISTS instead of IN for subqueries when appropriate
|
||||
- [ ] Avoiding functions in WHERE clauses that prevent index usage
|
||||
|
||||
### Index Strategy
|
||||
- [ ] Creating indexes on frequently queried columns
|
||||
- [ ] Using composite indexes in the right column order
|
||||
- [ ] Avoiding over-indexing (impacts INSERT/UPDATE performance)
|
||||
- [ ] Using covering indexes where beneficial
|
||||
- [ ] Creating partial indexes for specific query patterns
|
||||
|
||||
### Data Types and Schema
|
||||
- [ ] Using appropriate data types for storage efficiency
|
||||
- [ ] Normalizing appropriately (3NF for OLTP, denormalized for OLAP)
|
||||
- [ ] Using constraints to help query optimizer
|
||||
- [ ] Partitioning large tables when appropriate
|
||||
|
||||
### Query Patterns
|
||||
- [ ] Using LIMIT/TOP for result set control
|
||||
- [ ] Implementing efficient pagination strategies
|
||||
- [ ] Using batch operations for bulk data changes
|
||||
- [ ] Avoiding N+1 query problems
|
||||
- [ ] Using prepared statements for repeated queries
|
||||
|
||||
### Performance Testing
|
||||
- [ ] Testing queries with realistic data volumes
|
||||
- [ ] Analyzing query execution plans
|
||||
- [ ] Monitoring query performance over time
|
||||
- [ ] Setting up alerts for slow queries
|
||||
- [ ] Regular index usage analysis
|
||||
|
||||
## 📝 Optimization Methodology
|
||||
|
||||
1. **Identify**: Use database-specific tools to find slow queries
|
||||
2. **Analyze**: Examine execution plans and identify bottlenecks
|
||||
3. **Optimize**: Apply appropriate optimization techniques
|
||||
4. **Test**: Verify performance improvements
|
||||
5. **Monitor**: Continuously track performance metrics
|
||||
6. **Iterate**: Regular performance review and optimization
|
||||
|
||||
Focus on measurable performance improvements and always test optimizations with realistic data volumes and query patterns.
|
||||
Loading…
x
Reference in New Issue
Block a user