Agent Skills by ALSEL
Anthropic Claudeデータ・分析⭐ リポ 0品質スコア 50/100

optimizing-ef-core-queries

EF CoreクエリのN+1問題の解消、適切なトラッキングモードの選択、コンパイル済みクエリの活用、よくあるパフォーマンスの落とし穴の回避など、クエリを最適化します。EF Coreのクエリが遅い、大量のSQLが生成されている、データベース負荷が高い場合にご利用ください。

description の原文を見る

Optimize Entity Framework Core queries by fixing N+1 problems, choosing correct tracking modes, using compiled queries, and avoiding common performance traps. Use when EF Core queries are slow, generating excessive SQL, or causing high database load.

SKILL.md 本文

EF Core クエリの最適化

使用するべき場合

  • EF Core クエリが遅い、または多数の SQL ステートメントを生成している
  • ORM の非効率性により、データベースの CPU/IO が高い
  • ログで N+1 クエリパターンが検出されている
  • 大きな結果セットがメモリプレッシャーを引き起こしている

使用してはいけない場合

  • ユーザーが Dapper または raw ADO.NET を使用している (EF Core ではない)
  • パフォーマンス問題がデータベース側にある (インデックス不足、スキーマ設計)
  • ユーザーがゼロからデータアクセスレイヤーを構築している

入力

入力必須説明
遅い EF Core クエリはい最適化する LINQ クエリまたは DbContext の使用法
SQL 出力またはログいいえEF Core が生成した SQL またはクエリ実行ログ

ワークフロー

ステップ 1: クエリログを有効にして実際の SQL を確認する

// In Program.cs or DbContext configuration:
optionsBuilder
    .UseSqlServer(connectionString)
    .LogTo(Console.WriteLine, LogLevel.Information)
    .EnableSensitiveDataLogging()  // shows parameter values (dev only!)
    .EnableDetailedErrors();

または Microsoft.EntityFrameworkCore ログカテゴリを使用します:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.EntityFrameworkCore.Database.Command": "Information"
    }
  }
}

ステップ 2: N+1 クエリパターンを修正する

EF Core のパフォーマンス低下の最大の原因。 ループ内で関連エンティティを読み込むときに発生します。

修正前 (N+1 — 1 つの注文クエリ + N 件の項目クエリ):

var orders = await db.Orders.ToListAsync();
foreach (var order in orders)
{
    // Each access triggers a lazy-load query!
    var items = order.Items.Count;
}

修正後 (即時読み込み — 合計 1 ~ 2 クエリ):

// Option 1: Include (JOIN)
var orders = await db.Orders
    .Include(o => o.Items)
    .ToListAsync();

// Option 2: Split query (separate SQL, avoids cartesian explosion)
var orders = await db.Orders
    .Include(o => o.Items)
    .AsSplitQuery()
    .ToListAsync();

// Option 3: Explicit projection (best - only fetches needed columns)
var orderSummaries = await db.Orders
    .Select(o => new OrderSummary
    {
        OrderId = o.Id,
        Total = o.Items.Sum(i => i.Price),
        ItemCount = o.Items.Count
    })
    .ToListAsync();

Split クエリと Single クエリの使い分け:

シナリオ使用方法
Include が 1 段階Single クエリ (デフォルト)
複数の Include (直積のリスク)AsSplitQuery()
大きな子コレクションを含む IncludeAsSplitQuery()
トランザクション一貫性が必要Single クエリ

ステップ 3: 読み取り専用クエリに NoTracking を使用する

変更追跡のオーバーヘッドは大きい。 エンティティを更新する必要がない場合は無効にします:

// Per-query
var products = await db.Products
    .AsNoTracking()
    .Where(p => p.IsActive)
    .ToListAsync();

// Global default for read-heavy apps
services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking));

クエリが重複したエンティティを返す場合は AsNoTrackingWithIdentityResolution() を使用して、メモリ内の重複オブジェクトを回避します。

ステップ 4: ホットパスに対してコンパイル済みクエリを使用する

// Define once as static
private static readonly Func<AppDbContext, int, Task<Order?>> GetOrderById =
    EF.CompileAsyncQuery((AppDbContext db, int id) =>
        db.Orders
            .Include(o => o.Items)
            .FirstOrDefault(o => o.Id == id));

// Use repeatedly — skips query compilation overhead
var order = await GetOrderById(db, orderId);

ステップ 5: 一般的なクエリトラップを回避する

トラップ問題修正
Where() の前に ToList()テーブル全体をメモリに読み込む最初にフィルタリング: .Where().ToList()
存在確認に Count() を使用すべての行をスキャン.Any() を代わりに使用
.Include() の後に .Select()Include がプロジェクションで無視されるInclude を削除し、Select のみを使用
Where で string.Contains()翻訳されない可能性があるSQL LIKE に EF.Functions.Like() を使用
Select() 内で .ToList() を呼び出しネストされたクエリが発生Select で最後までプロジェクション

ステップ 6: 複雑なクエリに raw SQL または FromSql を使用する

LINQ で効率的に表現できない場合:

var results = await db.Orders
    .FromSqlInterpolated($@"
        SELECT o.* FROM Orders o
        INNER JOIN (
            SELECT OrderId, SUM(Price) as Total
            FROM OrderItems
            GROUP BY OrderId
            HAVING SUM(Price) > {minTotal}
        ) t ON o.Id = t.OrderId")
    .AsNoTracking()
    .ToListAsync();

検証

  • SQL ログに予想されたクエリ数が表示されている (N+1 なし)
  • 読み取り専用クエリが AsNoTracking() を使用している
  • ホットパスクエリがコンパイル済みクエリを使用している
  • ログにクライアント側評価の警告がない
  • Include/split 戦略がデータ形状と合致している

一般的なトラブル

トラブル解決策
遅延読み込みが静かに N+1 を作成しているMicrosoft.EntityFrameworkCore.Proxies を削除するか、遅延読み込みを無効にする
パフォーマンス分析で忘れられたグローバルクエリフィルターモデル構成で HasQueryFilter を確認; 必要に応じて IgnoreQueryFilters() を使用
DbContext を長時間保持しているDbContext はスコープ付き (リクエストごと) にすべき; キャッシュしない
一括更新がフェッチしてから保存しているEF Core 7+: 一括操作に ExecuteUpdateAsync / ExecuteDeleteAsync を使用
FromSqlRaw で文字列補間を使用SQL インジェクションのリスク — 代わりに FromSqlInterpolated (パラメータ化) を使用

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
dotnet
リポジトリ
dotnet/skills
ライセンス
MIT
最終更新
不明

Source: https://github.com/dotnet/skills / ライセンス: MIT

関連スキル

OpenAIデータ・分析⭐ リポ 1,451

hugging-face-trackio

Trackioを使用してMLトレーニング実験を追跡・可視化できます。トレーニング中のメトリクスログ記録(Python API)、トレーニング診断のアラート発火、ログされたメトリクスの取得・分析(CLI)が必要な場合に活用してください。リアルタイムダッシュボード表示、Webhookを使用したアラート、HF Space同期、自動化向けのJSON出力に対応しています。

by gradio-app
汎用データ・分析⭐ リポ 855

btc-bottom-model

ビットコインのサイクルタイミングモデルで、加重スコアリングシステムを搭載しています。日次パルス(4指標、32ポイント)とウィークリー構造(9指標、68ポイント)の2カテゴリーにわたる13の指標を追跡し、0~100のマーケットヒートスコアを算出します。ETFフロー、ファンディングレート、ロング/ショート比率、恐怖・貪欲指数、LTH-MVRV、NUPL、SOPR(LTH+STH)、LTH供給率、移動平均倍率(365日MA、200週MA)、週次RSI、出来高トレンドに対応します。市場サイクル全体を通じて買いと売りの両方の推奨を提供します。ビットコインの底値拾い、BTCサイクルポジション、買い時・売り時、オンチェーン指標、MVRV、NUPL、SOPR、LTH動向、ETFの流出入、ファンディングレート、恐怖指数、ビットコインが過熱状態か、マイナーコスト、暗号資産市場のセンチメント、BTCのポジションサイジング、「今ビットコインを買うべきか」「BTCが天井をつけているか」「オンチェーン指標は何を示しているか」といった質問の際にこのスキルを活用します。

by star23
Anthropic Claudeデータ・分析⭐ リポ 380

protein_solubility_optimization

タンパク質の溶解性最適化 - タンパク質の溶解性を最適化します。タンパク質の特性を計算し、溶解性と親水性を予測し、有効な変異を提案します。タンパク質配列の特性計算、タンパク質機能の予測、親水性計算、ゼロショット配列予測を含むタンパク質エンジニアリング業務に使用できます。3つのSCPサーバーから4つのツールを統合しています。

by SpectrAI-Initiative
Anthropic Claudeデータ・分析⭐ リポ 1,743

research-lookup

Parallel Chat APIまたはPerplexity sonar-pro-searchを使用して、最新の研究情報を検索できます。学術論文の検索にも対応しています。クエリは自動的に最適なバックエンドにルーティングされるため、論文の検索、研究データの収集、科学情報の検証に活用できます。

by K-Dense-AI
Anthropic Claudeデータ・分析⭐ リポ 299

tree-formatting

ggtree(R)またはiTOL(ウェブ)を使用して、系統樹の可視化とフォーマットを行います。系統樹を図として描画する際、ツリーレイアウトの選択、分類学に基づく枝やラベルの色付け、クレードの折りたたみ、サポート値の表示、またはツリーへのオーバーレイ追加が必要な場合に使用してください。系統推定(protein-phylogenyスキルを使用)やドメイン注釈(今後の独立したスキル)には使用しないでください。

by majiayu000
汎用データ・分析⭐ リポ 145

querying-indonesian-gov-data

インドネシア政府の50以上のAPIとデータソースに接続できます。BPJPH(ハラール認証)、BOM(食品安全)、OJK(金融適正性)、BPS(統計)、BMKG(気象・地震)、インドネシア中央銀行(為替レート)、IDX(株式)、CKAN公開データポータル、pasal.id(第三者法MCP)に対応しています。インドネシア政府データを活用したアプリ開発、.go.idウェブサイトのスクレイピング、ハラール認証の確認、企業の法的適正性の検証、金融機関ステータスの照会、またはインドネシアMCPサーバーへの接続時に使用できます。CSRF処理、CKAN API使用方法、IP制限回避など、すぐに実行可能なPythonパターンを含んでいます。

by suryast
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: dotnet · dotnet/skills · ライセンス: MIT