For a query like

SELECT * FROM t1  WHERE val1 < val2;

an index on (val1,val2) is never considered as a candidate, and so USE or FORCE can't be used on it, and a full table scan is done instead unless there's a covering index over all result columns.

There are edge cases though where only a small minority of rows actually fulfill the "val1 < val2" condition, I tested this with only 0.1% of rows matching. In that case an index scan with following random row lookups of the matching rows turns out to be faster than a full table scan.

The optimizer itself can't decide on this as it does not have statistics on the "less than" relationship between val1 and val2, and so will never consider using an index scan here.

A user may know about the data distribution, and so be able to decide that a FORCE INDEX may make sense here, but as the index is not even considered as a candidate it is also not available for FORCE