incident_components keeps an index that the July composite unique now covers

[albertoarena]

incident_components has a single column index on incident_id, from 2017_07_18_214718_CreateIncidentComponents.php:

$table->integer('incident_id')->unsigned()->index();

Since 2026_07_25_000002_add_constraints_to_component_pivots.php added the unique on (incident_id, component_id), that older index is a left prefix of the unique. MySQL and PostgreSQL can both answer a query filtering on incident_id alone from the composite, so the single column index no longer adds a read path. It is still maintained on every insert and update to the pivot, and still takes space.

Nothing here was written wrong. The composite arrived nine years after the single index, which is the ordinary way this happens.

schedule_components is not affected. It was constrained in the same migration, but its 2016 migration adds no single column indexes, so there is nothing to remove there.

The fix is to drop the index. An existing install needs a follow up migration; for new installs it is removing ->index() from the 2017 migration, though you may prefer not to edit a historical one.

Found with Laravel Truss, a structure only schema linter, running truss:doctor against a Cachet install. Checked against main today.