#### 8.2.1.23 避免全表扫描

[](<>)[](<>)[](<>)

从输出[`解释`](explain.html)节目[`全部`](explain-output.html#jointype_all)在里面`类型`MySQL 使用时的列[全表扫描](glossary.html#glos_full_table_scan)解决查询。这通常发生在以下情况下：

-   该表是如此之小，以至于执行表扫描比费心查找键要快。这对于少于 10 行且行长度较短的表很常见。

-   没有可用的限制`在`要么`在哪里`索引列的子句。

-   您正在将索引列与常量值进行比较，并且 MySQL 已经计算（基于索引树）常量覆盖了表的太大部分，并且表扫描会更快。看[第 8.2.1.1 节，“WHERE 子句优化”](where-optimization.html).

-   您正在通过另一列使用具有低基数的键（许多行与键值匹配）。在这种情况下，MySQL 假设通过使用键可能需要多次键查找，并且表扫描会更快。

    对于小型表，表扫描通常是合适的，性能影响可以忽略不计。对于大型表，请尝试以下技术以避免优化器错误地选择表扫描：

-   采用`分析表 *`tbl_name`*`更新扫描表的键分布。看[第 13.7.3.1 节，“ANALYZE TABLE 语句”](analyze-table.html).

-   采用`力指数`让扫描的表告诉 MySQL 与使用给定索引相比，表扫描非常昂贵：

    ```
    SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
      WHERE t1.col_name=t2.col_name;
    ```

    看[第 8.9.4 节，“索引提示”](index-hints.html).

-   开始[**mysqld**](mysqld.html)与[`--max-seeks-for-key=1000`](server-system-variables.html#sysvar_max_seeks_for_key)选项或使用`设置 max_seeks_for_key=1000`告诉优化器假设没有键扫描会导致超过 1,000 次键搜索。看[第 5.1.8 节，“服务器系统变量”](server-system-variables.html).
