An index is a trade-off, not a general speed switch. It may reduce the work needed for a read, while adding storage and maintenance cost to writes. Choose indexes based on a measured query pattern.
Start with the actual query
Identify the filter, join, ordering, and selected fields used by a real page or API. Use representative data and inspect the database query plan. A small development dataset can hide scans or cardinality patterns that matter at larger scale.
Understand composite index order
A composite index is most useful when its leading columns match the access pattern. Column order affects which filters and sorts can use it. Confirm the plan after adding an index and consider the cost to inserts and updates.
Inspect Eloquent relationship loading
Rendering a collection and lazily reading a relation for each row can create an N+1 query pattern. Eager loading can reduce repeated queries, but should be scoped to data the page needs. Query count and selected columns are useful checks.
Keep schema and index changes in reviewed migrations. Record the measured query and plan so a future developer can understand why the index exists.