I was in a presentation recently given by a Facebook MySQL engineer and he mentioned there that using FORCE INDEX reduces I/O.

It was something to do with the MySQL Query Optimizer not needing to go to the data dictionary and make calculations.

  • Can anyone explain how this works (preferably with references)?
  • Is this a good optimization practice to follow in general?
  • 4
    A quick Google query turned up the following blog post: A case for FORCE INDEX.
    – gonsalu
    Oct 28, 2011 at 14:59
  • 1
    I am almost certain that whatever Facebook does to optimize their MySQL environment counts as extreme and highly specialized optimization that only yields notable benefits at their massive, massive scale. The cost of using FORCE is in flexibility (your optimizer is bound) and maybe even performance (should you choose the wrong index, or should statistics change significantly). Still, I think the answers to this question should be informative. Oct 28, 2011 at 15:10
  • 1
    Hey Jonathan, to make this question more relevant and useful to the site (and keep it from being closed), I edited it to solicit more concrete information and recommendations, as opposed to just links. Oct 28, 2011 at 15:58

1 Answer 1


One good source to refer to on FORCE INDEX would be the book MySQL Database Design and Tuning.

MySQL Database Design and Tuning

On page 120 paragraph 4, it says:

Where does FORCE INDEX fit in? FORCE INDEX (first enabled in version 4.0.9) is very similar to USE INDEX; the main difference between the two options is that FORCE INDEX demands that MySQL use the index (if possible) in lieu of a more expensive table scan, whereas USE INDEX still allows the optimizer to choose a table scan.

The same page says that MySQL does not warn that an index is irrelevant and switches to a table scan in the case of USE INDEX.

Thus, FORCE INDEX can take the MySQL Query Optimizer out of the equation before using the index. Any query using FORCE INDEX properly will reduce I/O. Why do I say properly?

Think about it. If the index you choose to navigate through is a covering index and you only need the columns as listed in the covering index, contacting the table for data becomes unnecessary. All I/O is restricted to index pages. All the data requested is retrieved by performing index scans in the worst case. That is indeed a good thing if the requested data needs to be ordered, thus bypass any requested sorting.

In terms of "rules of engagements", FORCE INDEX should only be used when

  • referring to covering indexes
  • all columns in the index are small in size
  • you effectively tweek the caching behavior of SELECT queries
    • For adhoc queries, use SQL_NO_CACHE
    • For frequently updated data, cache judiciously

FORCE INDEX should not be made to force queries to use indexes if you are trying to fit a square peg in a round hole. In other words, traversing an index only to access table data in a specific order buys you nothing. In fact, it throws query performance under the bus because of not exercising any foreknowledge about how available your data needs to be.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.