database-optimizer
データベースパフォーマンスの最適化
クエリの実行速度の低下やデータベースパフォーマンスの不備は、アプリケーションの応答性を損なう可能性があります。このスキルでは、クエリ最適化、インデックス戦略、スケーラブルなアーキテクチャに関する専門的なガイダンスを提供し、データベースパフォーマンスを劇的に向上させます。
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "database-optimizer". この低速クエリを最適化してください：SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' AND o.created_at > '2024-01-01'
Résultat attendu:
分析:
1. **問題点**: SELECT * は不要なカラムを取得している; created_at にインデックスがない; status フィルターは選択的ではない可能性がある
推奨事項:
- カバリングインデックスを追加: CREATE INDEX idx_orders_customer_date ON orders(customer_id, created_at) INCLUDE (status, total)
- SELECT * を特定のカラムに置き換え
- テーブルが大きい場合は日付によるパーティショニングを検討
- customers.status に頻繁にフィルターをかける場合はインデックスを追加
Utilisation de "database-optimizer". 頻繁にアクセスされるデータベースクエリのためにキャッシングを実装するにはどうすればよいですか？
Résultat attendu:
マルチティアキャッシングアプローチ:
1. **L1（アプリケーション）**: ホットデータ用のインメモリキャッシュ（例：Go map、Python functools.lru_cache）
2. **L2（分散）**: TTL ベースの有効期限を持つ Redis
3. **キャッシュ戦略**: cache-aside パターンを使用 - まずキャッシュを確認し、ミス時に DB から読み込み、キャッシュに保存
4. **無効化**: 適切な TTL（例：5〜15 分）を設定するか、イベント駆動型の無効化を使用
5. **キー設計**: 特定のキャッシュエントリには 'user:123:orders' のような複合キーを使用
Audit de sécurité
SûrPrompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected no suspicious patterns. This is a pure instructional prompt providing database optimization guidance. No scripts, network calls, filesystem access, environment access, or external commands are present. No prompt injection attempts detected.
Score de qualité
Ce que vous pouvez construire
低速クエリのトラブルシューティングを行うアプリケーション開発者
開発者がデータベースクエリによりアプリケーションのページ読み込みが遅いことに気付いた場合、このスキルはクエリパターンの段階的な分析と最適化の推奨事項を提供します。
インデックス戦略を設計する DBA
データベース管理者が高トラフィックの E コマースアプリケーション向けのインデックス戦略を設計する必要がある場合、このスキルはインデックスタイプとカラム順序に関する包括的なガイダンスを提供します。
データベーススケーリングを計画するアーキテクト
ソフトウェアアーキテクトが増大する負荷に対応するためにモノリシックアプリケーションをスケーリングすることを計画している場合、このスキルはパーティショニング、シャーディング、キャッシング戦略に関するガイダンスを提供します。
Essayez ces prompts
この低速な SQL クエリの最適化を手伝ってください：[PASTE YOUR QUERY]。クエリ構造を分析し、パフォーマンス向上のための改善提案を行ってください。
[DESCRIBE YOUR WORKLOAD - 例：高頻度の読み取り、頻繁な更新] を処理する [DATABASE TYPE] データベース向けのインデックス戦略を設計してください。主なクエリパターンには [LIST QUERY PATTERNS] が含まれます。
[ORM NAME] アプリケーションで [DESCRIBE ENTITIES] を読み込む際に N+1 クエリ問題が発生しています。現在のコードは [DESCRIBE CURRENT PATTERN] を実行しています。これを最適化するにはどうすればよいですか？
データベースが [DESCRIBE PROBLEM - 例：高頻度の書き込み、負荷時の低速クエリ] を経験しています。現在のセットアップ：[DESCRIBE CURRENT ARCHITECTURE]。どのようなスケーリングと最適化戦略を推奨しますか？
Bonnes pratiques
- 最適化前に必ず測定してください - 推測ではなく、実際のクエリパフォーマンスを理解するために EXPLAIN ANALYZE を使用してください
- 理論的な知識ではなく実際のクエリパターンに基づいてインデックスを設計してください - アプリケーションの最も頻繁なクエリをプロファイリングしてください
- 回帰を早期に検出するために、低速クエリログとパフォーマンスベースラインによる包括的なモニタリングを実装してください
Éviter
- 『念のため』という理由で全てのカラムにインデックスを設定する - これは書き込みオーバーヘッドとストレージを増加させ、見合った効果がない
- ORM 内の N+1 クエリを無視する - 必ず Eager loading、バッチクエリ、または DataLoader パターンを使用する
- 特定のワークロードパターンとデータ分布を分析せずに一般的な最適化アドバイスを適用する