上文我们有提及到优化器的一些相关信息，如优化器的一些优化特性和限制，由此看出mysql优化器也并不是万能的。
所以mysql提供了另一种神奇的功能让我们去引导优化器进行更好的优化。
它就是 查询优化提示（Query Optimizer Hints）;
查询优化提示会提示优化器按照一定的方式去优化，让你的sql语句更具灵活性，这会让你的查询更快，
当然也可能更慢，这完全取决于你对优化器的理解和场景的了解。
现在让我们来了解有哪些查询优化提示：
优先操作 HIGH_PRIORITY 和 滞后操作 LOW_PRIORITY HIGH_PRIORITY可以使用在select和insert操作中，让MYSQL知道，这个操作优先进行。 SELECT HIGH_PRIORITY * FROM TABLE1; LOW_PRIORITY可以使用在select,delete,insert和update操作中，让mysql知道，这个操作滞后。 update LOW_PRIORITY table1 set field1= where field1= …
这两个提示都只在基于表锁的存储引擎非常有效。在innoDB和其他基于行锁的存储引擎，你可能永远用不上。
在MyISAM中使用它们时，也要十分小心，因为它们会让并发插入失效，可能会严重下降性能。 延时插入 DELAYED 这个操作只能用于 insert 和 replace INSERT DELAYED INTO table1 set field1= … INSERT DELAYED INTO，是客户端提交数据给MySQL，MySQL返回OK状态给客户端。而这是并不是已经将数据插入表，而是存储在内存里面等待排队。 当mysql有 空余时，再插入。另一个重要的好处是，来自许多客户端的插入被集中在一起，并被编写入一个块。这比执行许多独立的插入要快很多。 坏处是，不能返回自动递增 的ID，以及系统崩溃时，MySQL还没有来得及插入数据的话，这些数据将会丢失 straight_join
确定顺序的直接关联查询 sql_small_result sql_big_result 这两个提示只对select语句有效，它们告诉优化器对 group by 或者 distinct 查询如何使用临时表及排序。 sql_small_result 告诉优化器结果集会很小，可以将结果集放在内存中的索引临时表，以避免排序操作 sql_big_result 则告诉优化器结果集会很大，建议使用磁盘临时表做排序操作 sql_buffer_result 这个提示告诉优化器将查询放入到一个临时表，然后尽可能地释放锁。这和前面提到的由客户端缓存结果不同。当你设法使用客户端缓存的时候，使用服务器端的缓存通常很有效。 带来的好处是无须在客户端消耗太多的内存，还可以尽可能快的释放对应的表锁。代价是，服务器端需要更多的内存 sql_cache 和 sql_no_cache 这个提示告诉mysql是否讲结果集缓存在查询缓存中。 sql_calc_found_rows 严格来说，这并不是一个优化器提示。它不会告诉优化器任何关于执行计划的东西。 它会让mysql返回的结果集包含更多的信息。查询中加上该提示，mysql会计算出去limit子句后这个查询返回的结果集的总数。 而实际上只返回limit要求的结果集。可以通过函数found_row()获得这个值。 for update 和 lock in share mode 这两个提示主要控制select 语句的锁机制。但只对实现了行级锁的存储引擎有效。使用该提示会对符合查询条件的数据加锁。 对于insert...select 语句不需要这两个提示，因为会默认添加上锁。 唯一内置的支持这两个提示的引擎是innoDB。另外需要记住的是，这两个提示会让某些优化无法进行。例如索引覆盖扫描。 innoDB不能在不访问主键的情况下用排他锁锁定行，因为行的信息锁定在主键中。 use index, ignore index 和 force index 这几个提示用来告诉优化器是否使用索引来查询记录。 force index 和 use index 基本相同，除了一点：force index 会告诉优化器全表扫描的成本 会远远高于索引扫描，哪怕实际该索引用处不大。 新增参数控制优化器的行为： optimizer_search_depth optimizer_prune_level 该参数默认打开的，这让优化器会根据需要扫描的行数来决定是否跳过某些执行计划。 optimizer_switch 这个变量包含了一些开启/关闭优化器特性的标志位。例如mysql5.1 可以通过控制这个参数来控制禁用索引合并的特性。