Left to Right

A table has one composite index on (tenant_id, created_at). A new query filters only on created_at with no tenant_id predicate, and it runs far slower than expected. What is happening?

Composite indexes only support equality predicates on their columns, so a timestamp compared with a range operator can never drive one

Without the leading column the engine cannot seek into the index, so at best it scans every index entry, and the planner usually just reads the table instead

The optimizer reorders composite index columns to fit each query, so the index is used normally here and the slowness must come from stale statistics that a refresh will fix

The index seek still works, but because created_at is the second column every matching entry has to be sorted before the rows can be returned