- How do I install gigerit/laravel-mysql-optimizer in a Laravel app?
- Install it with composer require gigerit/laravel-mysql-optimizer. The service provider is auto-discovered through extra.laravel.providers, so no manual registration is required. Optionally publish the mysql-optimizer.php config file with vendor:publish if you need to change the target database or other defaults. There are no migrations, models, routes, or other application files to worry about.
- Which Laravel and PHP versions does this MySQL optimizer support?
- The repository's AGENTS.md asserts Laravel 8 through 13 and PHP 8.2 through 8.5 in CI, but that should be verified against the actual composer.json constraints before you rely on it. Any Laravel 8+ application running MySQL or MariaDB fits the package's integration model, since it only adds a console command, a job, and a service provider. Check the composer.json require block on the tagged release you plan to use.
- What does the db:optimize Artisan command actually do to my tables?
- It runs OPTIMIZE TABLE against the target database's tables, which InnoDB maps to ALTER TABLE ... FORCE, a full table rebuild that reclaims space and defragments the table. Under the hood it is a thin wrapper: the command calls an OptimizeTablesAction, and a queueable OptimizeTablesJob is available for background runs. Results are logged to the Laravel log as table, success flag, and timestamp unless you pass --no-log.
- How do I schedule db:optimize to run automatically in Laravel?
- Add the command to your scheduler in routes/console.php or the console kernel, for example Schedule::command('db:optimize')->weekly(). Because the entire integration boundary is a scheduled command that issues DDL, you can scope it with --table or push it to the queue with --queued. Be mindful that a rebuild can be I/O heavy, so schedule it for low-traffic windows on large databases.
- Does this package support MariaDB or only MySQL?
- The package description claims MySQL and MariaDB support, but the integration CI suite only exercises MySQL 8.0, so MariaDB behavior is assumed rather than empirically verified in the repo. OPTIMIZE TABLE semantics differ slightly between MySQL and MariaDB, especially for InnoDB rebuilds. Test the command against your exact MariaDB version before scheduling it in production.
- Can I optimize only specific tables with the --table option?
- Yes, the --table option is repeatable, so you can scope a run to one or more named tables instead of the whole schema. This is the recommended approach on large databases where a full rebuild of every table would cause excessive I/O or replication lag. Combine it with --queued if you want the scoped run to execute in the background.
- How does the --queued option work with OptimizeTablesJob?
- Passing --queued dispatches an OptimizeTablesJob, which implements ShouldQueue and ShouldBeUnique so duplicate rebuilds are not queued concurrently. The package docs warn that the job's $backoff does not extend Redis retry_after, and that the job timeout plus a safety margin must fit under retry_after; Horizon supervisors need their own timeout configured between the two. Get those values right before pointing the job at a large table.
- Is there a dry-run mode to preview what OPTIMIZE TABLE would do?
- No. The documented command signature is limited to --database, --table, --queued, and --no-log, and there is no --dry-run flag. The package also ships no pre-flight guardrails such as a free-disk-space check or a fragmentation gate that reads data_free to decide whether a table is worth rebuilding. If you need that safety layer, you will have to build it around the command yourself.
- What database privileges does the optimizer need, and is that a security concern?
- The app's database user needs SELECT and INSERT on the tables being optimized, plus the privileges OPTIMIZE TABLE requires for the rebuild. On managed services the grant set may differ or be restricted, and granting an application user DDL-capable permissions is a security decision rather than a package one. Review your grants and consider running the command under a dedicated connection or role.
- Is OPTIMIZE TABLE safe to run on large production tables?
- On InnoDB, OPTIMIZE TABLE is an online but I/O-heavy full rebuild: it takes a metadata lock, needs roughly the table's size in free disk, and creates replication lag on large tables. The 3600s default job timeout may not be enough for your biggest table, so measure rebuild time first. Also check whether you are targeting a primary, a replica, or an Aurora/RDS instance, since managed engines often restrict or reinterpret OPTIMIZE.