【IT专家】Mysql避免全表扫描sql查询优化 .

本文由我司收集整编，推荐下载，如有疑问，请与我司联系

Mysql避免全表扫描sql查询优化.

2013/06/24 0 Explain的type显示的是访问类型，是较为重要的一个指标，结果从好到坏依次是：system const eq_ref ref fulltext ref_or_null index_merge unique_subquery index_subquery range index ALL一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。Explain的Extra信息也相当重要，如果此信息显示Using filesort或者Using temporary的话，噩梦即将开始，不过也不尽然，比如说在一个WHERE ... ORDER BY ... 类型的查询里，很多时候我们无法创建一个兼顾WHERE和ORDER BY的索引，此时如果按照WHERE 来确定索引，那么在ORDER BY时，就必然会引起Using filesort，文件排序是好是坏需要仔细判断，说白了就是看是先过滤再排序划算，还是先排序再过滤划算，正确答案取决与数据分布的情况，具体的情况可以参考Using index for ORDER BY vs restricting number of rows。

 对查询进行优化，应尽量避免全表扫描，首先应考虑在where 及order by 涉及的列上建立索引:

 .尝试下面的技巧以避免优化器错选了表扫描：

 ·使用ANALYZE TABLEtbl_name为扫描的表更新关键字分布。

 ·对扫描的表使用FORCEINDEX告知MySQL，相对于使用给定的索引表扫描将非常耗时。

 SELECT * FROM t1, t2 FORCE INDEX (index_for_column)

 WHERE t1.col_name=t2.col_name；

 ·用--max-seeks-for-key=1000选项启动mysqld或使用SET

max_seeks_for_key=1000告知优化器假设关键字扫描不会超过1,000次关键字搜

索。

 1. 应尽量避免在where 子句中对字段进行null 判断，否则将导致引擎放弃使用