Doctrine Query Statistics Bundle Laravel Package

Getting Started

• Confirm you're on a legacy Symfony 2.x/3.x stack with doctrine/doctrine-bundle and the Web Profiler enabled — this bundle targets that era and is archived, so it is a maintenance-only tool, not something to introduce into new projects.
• Install as a dev dependency: composer require --dev sensiolabs/doctrine-query-statistics-bundle.
• Register the bundle only in config_dev.yml/AppKernel dev branch (or config/bundles.php if you've backported the bundle into a Symfony 4 app). Add SensioLabs\Bundle\DoctrineQueryStatisticsBundle\SensioLabsDoctrineQueryStatisticsBundle to the dev/test bundle list.
• Look first at the bundle's DependencyInjection/Configuration.php, its DataCollector, and its SQL logger decorator — those tell you exactly which config keys exist (typically enable/disable and thresholds) and how queries are intercepted.
• First use case: open any page in the dev environment, click the Web Profiler toolbar, and select the new Doctrine Query Statistics panel. You'll see queries aggregated by SQL text with execution counts and cumulative timings — the fastest way to spot N+1 and repeated queries on a page.
• Verify the profiler itself is on: framework.profiler in config_dev.yml, and that DBAL logging is enabled (doctrine.dbal.logging: true or the profiler middleware, depending on Symfony version).

Implementation Patterns

• Pre-optimization audit workflow: browse each suspect route in dev, note grouped query counts and total time per SQL statement, then open the native Doctrine panel to correlate with call stacks. Drill into duplicates first — one query repeated N times is usually a lazy-loading loop.
• Compare before/after: capture the statistics panel for a route, apply a fix (eager loading, join fetch, batch fetch), then reload and compare the same aggregation view. Because the bundle groups by SQL, the count column is a reliable proxy for N+1.
• Test-environment assertion: register the bundle in test too, run functional tests through a kernel request, pull the collector from the profiler ($client->getProfile()->getCollector('...')) and assert query counts/timings stayed within a budget. This turns the panel's data into regression protection.
• Pair with deep profilers: use this bundle to find which queries are expensive or repeated, then use Blackfire/XHProf for stack-level attribution. Keep it as the cheap first pass.
• Custom collectors: if the shipped aggregations don't match your team's metrics (e.g., queries per repository, slow-query thresholds), subclass or mirror the bundle's DataCollector, reuse its logger decorator, and register the collector with the data_collector tag and a template under Resources/views/Collector/.
• Template overrides: copy the collector template into app/Resources/SensioLabsDoctrineQueryStatisticsBundle/ (or equivalent) to add columns or filters without touching vendor code.
• CI hygiene: because profiler panels are dev-only, ensure production config excludes the bundle and that CI dev caches don't ship profiler output.

Gotchas and Tips

• Archived: no fixes, no Symfony 5+/PHP 8 compatibility guarantees. Pin the exact version in composer.json, and be ready to fork or vendor it if patching is needed. Check PHP constraints before installing on an upgraded runtime.
• Symfony-only: there is no Laravel integration. A Laravel developer will only encounter this bundle while maintaining an old Symfony app; for Laravel, use Debugbar/Telescope with its query tab instead, and translate these patterns (grouping, duplicate counting, per-route comparison).
• Dev-only registration: leaving it enabled in prod adds logger overhead and risks exposing SQL in any profiler remnants. Keep the bundle registration and framework.profiler strictly in config_dev.yml.
• Missing queries: if the panel is empty, verify DBAL logging is active and that no other SQLLogger/middleware decorator replaced the one the bundle expects. Logger decorators do not always stack cleanly.
• Profiler overhead: pages with thousands of queries can blow up profiler memory/response time. Use the config's exclusion options (or a custom filter) for very chatty endpoints.
• Duplicate detection is text-based: queries differing only in bound parameters may be grouped together or split depending on how the collector keys them — don't assume one row equals one prepared statement.
• Container/cache quirks: after changing bundle config, cache:clear (or rm -rf var/cache/dev) and re-check; stale dev caches frequently make config changes look ignored.
• Debugging the collector: inspect the profiler token's data in var/cache/dev/profiler/ (or the _profiler route) to see the raw collected array when the tab renders incorrectly.
• Extension points to lean on: the collector service definition, the logger decorator service, the config tree, and the Twig collector template — override services in services.yml rather than editing vendor code so the bundle can still be removed cleanly.