Precise N+1 Detection for Go via Interprocedural Dataflow Analysis

[kiarash8112]

Hi everyone,

I'm working on Query Controller, a static analyzer for Go that detects true, data-dependent N+1 database query patterns — not just "there is a query inside a loop."

The Problem

Most N+1 detectors (and many linters) use simple heuristics: if a DB call appears inside a for/range, flag it. That produces a lot of noise. Many loop queries are perfectly fine when arguments are constants or don't depend on the iteration variable.

What I care about is the case where loop data actually flows into query arguments across function boundaries — the classic pattern:

for _, u := range users {
    GetUser(db, u.name)
}

func GetUser(db *GormDB, u string) {
    db.Where("it is", u).Find(nil) // dynamic arg → N+1
}

What Query Controller Does

It uses IFDS-style tabulation over Go SSA.

Phase 1 — Trace Query Arguments

Seed GORM-style query sinks (Where, Raw, Query, Exec, etc.) and trace arguments backward through:

• Assignments
• Stores
• Interprocedural call edges
• Return flows

Phase 2 — Detect True N+1 Patterns

Report only when the traced value:

• Is non-constant
• Depends on loop iteration (phi nodes, indexed access, etc.)
• Reaches a query sink
• Occurs inside a loop that also executes a DB operation (Find, Scan, First, etc.)

Implementations

There are currently two implementations in the repository:

1. Standalone CLI

A stack-based IFDS prototype located at the repository root.

2. golangci-lint Plugin

Located under analyzerVersion/.

The plugin performs cross-package analysis using:

• SinkParamFact
• ReturnToParamFact
• ExecutorFact

Example Diagnostic

🚨 [TRUE N+1] Found dynamic database execution in loop (detected via dataflow)

Current Status

✅ GORM-style APIs are modeled

✅ Cross-package analysis works in the golangci-lint plugin

✅ Test fixtures cover:

• Nested calls
• Tuple returns
• Recursion
• Dynamic query building
• Other real-world dataflow scenarios

Known Limitations

• GORM method names only (no sqlx, ent, pgx, etc. yet)
• Standalone CLI currently has a call-stack depth limit
• Plugin requires a custom golangci-lint build

Questions for the Community

I'd love feedback on the following:

Usefulness

Is precision-focused N+1 detection something you'd run in CI, or is batching/preload guidance generally enough?

ORM Coverage

Which Go database libraries should be supported next?

• sqlx
• ent
• database/sql
• pgx
• Others?

Integration

Which delivery model would you prefer?

• golangci-lint plugin
• Standalone go vet-style analyzer
• Language server integration
• Something else

False Negatives / Positives

What N+1 patterns in real codebases would you expect this approach to miss or incorrectly flag?

Contributions

Any interest in helping with:

• Additional sink/executor definitions
• ORM support
• Real-world test cases
• Performance improvements

Repository

Repo: https://github.com/kiarash8112/query-controller

The README contains setup instructions for both the standalone CLI and the golangci-lint plugin.

---

Thanks! Any thoughts, war stories, edge cases, or feedback would be greatly appreciated.

[ldez]

Message to the community

This repo contains several binary files.
This is a security red flag.

The code is not Go idiomatic and the design is weird.

The author seems to think that spamming the Go community (not only golangci-lint) with AI generated discussion is something good...

I'm recommendation is to not use this analyzer.