‫بهینه‌سازی انقلابی مکانیزم Split Queries در EF Core 11

var result = context.Blogs
    .Include(x => x.BlogType) // ناوبری مرجع (Reference Navigation)
    .Include(x => x.Posts)    // ناوبری مجموعه‌ای (Collection Navigation)
    .AsSplitQuery()
    .ToList();

SELECT [b].[Id], [b].[BlogDetailId], [b].[BlogTypeId], [b].[Name], [b0].[Id], [b0].[Type]
FROM [Blogs] AS [b]
LEFT JOIN [BlogType] AS [b0] ON [b].[BlogTypeId] = [b0].[Id]
ORDER BY [b].[Id], [b0].[Id]

SELECT [p].[Id], [p].[BlogId], [p].[Title], [b].[Id], [b0].[Id]
FROM [Blogs] AS [b]
LEFT JOIN [BlogType] AS [b0] ON [b].[BlogTypeId] = [b0].[Id]
INNER JOIN [Post] AS [p] ON [b].[Id] = [p].[BlogId]
ORDER BY [b].[Id], [b0].[Id]

⚠️ اثر تجمعی ناکارآمدی (Cumulative Degradation Effect):

اگر در یک پروژه واقعی، موجودیت ریشه شما به جای یک رابطه مرجع، دارای پنج یا ده رابطه مرجع (مانند Author، Category، Status و...) باشد، این نقص فنی به صورت تصاعدی تشدید می‌شود. در EF Core 10، به ازای تک‌تک کوئری‌های مجموعه‌ای فرزند، تمام آن ۵ یا ۱۰ جدول مرجع مجدداً JOIN و ORDER BY می‌شدند. نتیجه این امر، تحمیل بار پردازشی سنگین به موتور بهینه‌ساز پایگاه داده (Query Planner)، اشغال بیهوده حافظه پنهان و افت شدید کارایی کل سیستم بود.

SELECT [p].[Id], [p].[BlogId], [p].[Title], [b].[Id]
FROM [Blogs] AS [b]
INNER JOIN [Post] AS [p] ON [b].[Id] = [p].[BlogId]
ORDER BY [b].[Id]

[MemoryDiagnoser]
[SimpleJob(RuntimeMoniker.Net10_0)]
[SimpleJob(RuntimeMoniker.Net11_0)]
public class SplitQueryBenchmarks
{
    private SqliteConnection _connection = null!;
    private DbContextOptions<BloggingContext> _options = null!;

    [GlobalSetup]
    public void Setup()
    {
        _connection = new SqliteConnection("Data Source=:memory:");
        _connection.Open();

        _options = new DbContextOptionsBuilder<BloggingContext>()
            .UseSqlite(_connection)
            .Options;

        using var context = new BloggingContext(_options);
        context.Database.EnsureCreated();
        Seeder.Seed(context, blogCount: 5_000, postsPerBlog: 5);
    }

    [GlobalCleanup]
    public void Cleanup() => _connection.Dispose();

    [Benchmark]
    public List<Blog> SplitQuery()
    {
        using var context = new BloggingContext(_options);
        return BlogQuery(context).AsSplitQuery().ToList();
    }

    private static IQueryable<Blog> BlogQuery(BloggingContext context)
        => context.Blogs
            .AsNoTracking()
            .Include(b => b.Author)
            .Include(b => b.Category)
            .Include(b => b.Series)
            .Include(b => b.Posts);
}

💡 نکته مهندسی و تحلیل معماری تجاری:

توجه داشته باشید که این بنچمارک روی دیتابیس درون‌حافظه‌ای SQLite اجرا شده است که در آن هزینه JOIN و ارتباطات به دلیل عدم وجود لایه شبکه فیزیکی بسیار ناچیز است. در محیط‌های عملیاتی صنعتی (Enterprise) که از بانک‌های اطلاعاتی مجزا مانند SQL Server یا PostgreSQL استفاده می‌کنند، حذف لایه‌های اضافی پیوند (JOIN) و کاهش پهنای باند شبکه، تاثیر به مراتب چشمگیرتری (گاهی تا چندین برابر بهبود کارایی) در کاهش تاخیر (Latency) کل لایه داده خواهد داشت.

• تعدد رفت‌وبرگشت‌های شبکه (Network Roundtrips): تفکیک دستورات به معنای اجرای چندین لایه کوئری مجزا است. اگر تاخیر شبکه (Network Latency) بین سرور برنامه و سرور دیتابیس بالا باشد، هزینه رفت‌وبرگشت‌های متعدد ممکن است از مزیت حذف انفجار دکارتی پیشی بگیرد.
• عدم ثبات و یکپارچگی داده‌ها (Non-Atomic Operations): بر خلاف کوئری واحد که در قالب یک تراکنش واحد و منسجم، نمایی پایدار از داده‌ها (Snapshot) را برمی‌گرداند، در Split Queries هر کوئری در تراکنش مجزای خود اجرا می‌شود (مگر اینکه به طور صریح تراکنش سراسری تعریف شده باشد). این یعنی اگر داده‌ای بین اجرای کوئری اول و کوئری دوم توسط کاربر دیگری تغییر کند، احتمال بروز پدیده داده‌های ناسازگار (Inconsistent Data) وجود دارد.

• گزارش رسمی و بررسی خطاهای گیت‌هاب دات‌نت
• مستندات مرجع مایکروسافت در رابطه با معماری Single vs. Split Queries