問題

生成環境，同一條sql在不同的從庫執行，產生的執行計劃不同，一個使用了索引，一個未使用索引

explain SELECT * FROM `database`.`table` FORCE INDEX(create_time) WHERE create_time >= 1508360400 and create_time <= 1508444806 ORDER BY create_time asc LIMIT 4000, 1000;

原因分析

1. 分析是否是取值limit太大，超過count的1/3，Innodb引擎不使用索引。經分析共計有6000多條數據，索引這個原因可以排除
2. 相同的sql在不同的從庫執行，一個未使用索引，分析是索引文件或者表的碎片導致，后咨詢阿里DBA給分析是表的碎片問題導致產生的執行計劃不正常

解決方案

1. 方案1：執行OPTIMIZE TABLE修復碎片或者執行ALTER TABLE foo ENGINE=InnoDB，以上兩種操作都會鎖表，對于數據量大，且業務高峰期執行需要慎重

2. 方案2：強制索引，也就是FORCE index create_time，強制mysql 引擎使用索引，這里需要注意一下，當使用強制索引時，存儲引擎會檢查強制索引是否可用，如果不可用，還需要掃描表來判斷那種執行計劃，官方說明：

   The FORCE INDEX hint acts like USE INDEX (index_list), with the addition that a table scan is assumed to be very expensive. In other words, a table scan is used only if there is no way to use one of the named indexes to find rows in the table.
   

   也不用擔心有副作用，如果強制索引可用，正好能提要索引選擇的效率

參考鏈接：

http://blog.csdn.net/u011575570/article/details/48092403

https://dev.mysql.com/doc/refman/5.7/en/index-hints.html