Laravel Mysql Advisor Laravel Package

Product Decisions This Supports

• Performance triage without a DBA on retainer. The 13 checks map to the failure modes that actually show up in Laravel apps: unindexed-foreign-key and n-plus-one for ORM-driven slowness, full-table-scan and top-statements for query-plan regressions, buffer-pool-hit-ratio and disk-temp-tables for under-provisioned instances. A PM can use the report to argue for a specific infra tier or a specific sprint of index work instead of a vague "the app is slow."
• Scoping the "just add indexes" backlog. Each finding ships with the fix as SQL plus a Laravel migration or Eloquent snippet. That converts a report into estimated tickets with near-zero engineering discovery time — directly useful for sizing a hardening sprint or a pre-launch checklist.
• Build vs. buy for observability. This partially covers ground that Percona PMM, MySQL Enterprise Monitor, or a managed-provider insight panel would cover. If the team already pays for one of those, this is redundant for server-level checks; if not, it defers a paid-tool decision for another quarter.
• Environment-gating policy. The viewMysqlAdvisor gate defaults to local-only. That is a reasonable default, but it is a decision the PM should ratify explicitly: does production schema diagnostics get exposed to on-call, or stay on staging/pre-prod?
• CI gating as a product-quality lever. --fail-on with exit code 1 on findings and 2 on inspection failure makes this usable as a pipeline gate. That is a policy call — gating merges on advisory findings will create friction and needs a defined severity threshold — but it's cheap insurance against reintroducing dropped indexes.
• Use cases by stage: pre-launch schema review, post-incident "why did this get slow," periodic hygiene on redundant-index/fragmentation/stale-statistics, and onboarding documentation for engineers who don't know MySQL internals.

When to Consider This Package

Adopt when:

• You run MySQL 8 or MariaDB 10.6+ and are on Laravel (the migration/Eloquent output is the differentiator).
• You don't have a dedicated DBA or a paid database observability tool, and slow-query work is currently ad hoc.
• You want read-only, safe-by-construction diagnostics — ReadOnlyGuard permitting only a single SELECT or SHOW is the right guarantee for pointing anything at production, and it makes security review short.
• You value no frontend build step: the Blade dashboard ships without assets, so it drops into an existing deploy pipeline.
• You need output that is actionable by Laravel engineers rather than raw EXPLAIN dumps.

Look elsewhere or wait when:

• Version risk. This is v0.1.0. There is no track record, no published stability policy, and 13 checks is a deliberately narrow surface. Treat it as a supplement, not the whole answer.
• You need history, trending, or alerting. This is a point-in-time report, not a monitoring system. No time series, no regression detection, no notifications.
• You need remediation. Nothing is ever executed — by design and, given production safety, correctly so. If you want automated index creation, this is not that tool.
• Your app uses native prepared statements. The release notes explicitly call out that these are invisible to performance_schema digests, so the query-level checks (top-statements, n-plus-one, full-table-scan) will degrade to skipped. If that's your stack, a large share of the value is gone — verify before committing.
• performance_schema is off or privileges are restricted on managed MySQL (common on some providers). The graceful-degradation messaging is good product behavior, but skipped checks mean skipped value. Confirm the GRANTs are obtainable in your environment first.
• You already run Percona PMM or an equivalent with dashboards your team trusts — the server-level checks add little.

How to Pitch It (Stakeholders)

For executives: This is a free, low-risk diagnostic that tells us which database problems are costing us performance and exactly what to change to fix them. It reads only — it cannot modify or break production — and it runs as a single command or a local dashboard with no new infrastructure, no vendor contract, and no frontend build. It buys us the kind of visibility we would otherwise staff a DBA or buy a monitoring product for, and it turns "the app feels slow" into a sized list of tickets. Honest caveat: it's a first release with 13 checks, so we should pilot it on staging for a sprint before we rely on it, and it complements rather than replaces a real monitoring tool.

For engineering: Zero-execution guarantee via ReadOnlyGuard (single SELECT/SHOW only) means it's safe to point at production. One artisan command with --only, --connection, --format=json, and --fail-on for CI; a gate-protected Blade dashboard with no asset pipeline; and a php artisan about entry. Every finding comes with the fix as SQL plus a Laravel migration or Eloquent snippet. It degrades honestly — missing privileges, performance_schema disabled, or native prepared statements produce a skipped check with the reason and the exact GRANT or setting needed, rather than a silent false negative. Ask: is v0.1.0 acceptable as a dependency, and can we get the required grants in each environment?