- How do I install tpetry/laravel-mysql-explain in a Laravel app?
- Install it as a development dependency with composer require --dev tpetry/laravel-mysql-explain. Laravel package auto-discovery registers the service provider, so no migrations or mandatory config publishing are required. You can then use the query builder and Eloquent EXPLAIN macros or the Artisan entry point against your MySQL or MariaDB connection.
- Which Laravel and PHP versions does laravel-mysql-explain support?
- The package is built for Laravel applications using MySQL or MariaDB, but you should verify its composer.json constraints against your current Laravel and PHP matrix before pinning it. Compatibility also depends on your database version because EXPLAIN output formats differ across MySQL 5.7, MySQL 8.x, and MariaDB. Treat MariaDB as test-before-trusting until you have validated rendering against a known query.
- How do I get a visual EXPLAIN plan for an Eloquent query?
- Use the package's query-builder macro on the exact query Eloquent emits, for example by calling explain() on the builder before execution. It wraps MySQL or MariaDB EXPLAIN JSON output and renders it as a human-readable plan tree so you can review access paths and row estimates. This avoids manually copying SQL into a separate database client.
- Does laravel-mysql-explain work with MariaDB or only MySQL?
- It targets MySQL and MariaDB only and provides no value for PostgreSQL or SQLite applications. MariaDB should be validated in your environment because plan formats and supported EXPLAIN features vary by vendor and version. Confirm that your MariaDB version and account permissions support the EXPLAIN options you intend to use.
- What is the difference between EXPLAIN and EXPLAIN ANALYZE in this package?
- A normal EXPLAIN returns the optimizer's plan without executing the statement. EXPLAIN ANALYZE actually runs the query and returns runtime information, which is available in MySQL 8.0.18 and later. Because ANALYZE executes the statement, restrict it to local databases or read replicas and never point it at a heavy query on a production primary.
- Can I use laravel-mysql-explain in production?
- It is developer tooling, not runtime infrastructure, so install it with require-dev and keep it out of production images, request paths, and unattended job pipelines. If your incident-response process depends on it, make that availability explicit rather than assuming a dev dependency will be installed on every host. In particular, do not run EXPLAIN ANALYZE against production primaries.
- Does the package require configuration or database migrations?
- No migrations are required and it does not change your schema. Laravel auto-discovery is enough to begin using it, and publishing configuration is optional if you want to pin defaults. The main prerequisite is a MySQL or MariaDB connection whose database account is allowed to run EXPLAIN and, where used, EXPLAIN ANALYZE.
- How do I find missing indexes for a slow Laravel Eloquent query?
- Run explain() on the exact builder query that Eloquent generates, then inspect the rendered plan tree for full table scans, high row estimates, and expensive join or sort steps. Use the plan to decide which columns need indexing, then re-run the same query after adding the index and compare plans. Keep this workflow in your performance runbook rather than using it only as a one-off novelty.
- Is the EXPLAIN output safe to paste into tickets or CI logs?
- Execution plans can expose table names, column names, index names, and row estimates, so treat the rendered output as sensitive schema detail. Redact identifiers before sharing plans in tickets, shared CI logs, or telemetry. Also confirm your team's policy for where plan output is stored, because pasted plans can outlive the debugging session.
- What alternatives exist to laravel-mysql-explain and is it actively maintained?
- Alternatives include running raw EXPLAIN FORMAT=JSON in a MySQL client, using MySQL Workbench's visual explain, or combining Laravel Telescope and Debugbar for query timing while inspecting plans separately. This package is a small, single-maintainer project with a modest community, so pin a known-good version and schedule periodic compatibility reviews. Have a fork or vendor contingency in case upstream maintenance slows.