Make an important order-search query identifiable in telemetry and inspect its generated SQL during investigation.

• Use a constant, stable tag.
• Keep sensitive and high-cardinality data out of SQL comments.
• Use ToQueryString for diagnosis, not query execution.
• Still measure the actual command and plan with representative parameters.

I tag the query near its definition so the identifier survives refactoring and appears in generated SQL. Locally, ToQueryString reveals translation, selected columns, joins, ordering, and parameters. In production, dependency telemetry and database tools provide timing and plans; I do not enable detailed sensitive logging globally just to find one endpoint.

public static IQueryable<OrderSearchItem> BuildOrderSearch(
    AppDbContext db,
    OrderSearch request)
{
    var query = db.Orders
        .AsNoTracking()
        .TagWith("Orders.Search.v1")
        .Where(order => order.CreatedAtUtc >= request.FromUtc)
        .Where(order => order.CreatedAtUtc < request.ToUtc);

    if (request.Status is not null)
        query = query.Where(order => order.Status == request.Status);

    return query
        .OrderByDescending(order => order.CreatedAtUtc)
        .ThenByDescending(order => order.Id)
        .Select(order => new OrderSearchItem(
            order.Id,
            order.Status,
            order.CreatedAtUtc,
            order.Total));
}

// Local investigation only; do not log this on every production request.
var generatedSql = BuildOrderSearch(db, request).Take(100).ToQueryString();

The tag changes observability, not query complexity. The final query remains parameterized and bounded by the caller. Useful investigation follows the tag from request telemetry to actual SQL duration, row estimates, logical reads, and execution plan.

• Different optional status values produce different selectivity.
• A developer is tempted to include request data in the tag.
• Generated SQL looks reasonable but the production plan is poor.
• The query lacks a final result limit at the endpoint boundary.

• Assert the generated SQL contains the stable tag.
• Verify no user input appears in the tag text.
• Compare plans for representative status and date ranges.
• Correlate one tagged dependency back to the endpoint trace.

• Putting email, tenant id, or search text into the SQL comment.
• Logging generated SQL on every production request.
• Treating ToQueryString as performance measurement.
• Changing LINQ blindly without reading the plan and row counts.