Frankly, I think that the advice pretends to
force ASE *not* to use an index on ORDER_NUM.
Perhaps there's a better access path that
ASE had better using instead.
I can imagin a situation where ORDER_NUM
grows at high speed, so histogram
statistics keep soon outdated. ASE's
optimizer may think 53320 is so close
to the maximum than the condition
ORDER_NUM >= 53320
is supposed to retrieve few rows; that
is, ASE thinks ORDER_NUM is a good
choice for an index access. But this
could be wrong because now there are
thousands of rows with ORDER_NUM
higher than 53320