V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
ecloud
V2EX  ›  MySQL

是什么造成 explain 中显示的 type 为 ALL?

  •  
  •   ecloud ·
    yecloud · 2022-02-23 14:10:30 +08:00 · 1250 次点击
    这是一个创建于 798 天前的主题,其中的信息可能已经有所发展或是发生改变。

    一个比较复杂的查询,explain 一共有 10 条记录

    其中有几条的 type 为 ALL ,key 也为空

    但是该字段的确建立了索引,并且查询条件是=

    是不是 group by 里面的字段跟 where/join on 里面的字段要在一起建联合索引?

    id|select_type |table             |partitions|type  |possible_keys                           |key                  |key_len|ref                                         |rows|filtered|Extra                       |
    --+------------+------------------+----------+------+----------------------------------------+---------------------+-------+--------------------------------------------+----+--------+----------------------------+
     1|PRIMARY     |<derived4>        |          |ALL   |                                        |                     |       |                                            |1092|   100.0|                            |
     1|PRIMARY     |<derived3>        |          |ref   |<auto_key0>                             |<auto_key0>          |152    |a.login                                     |   6|   100.0|                            |
     3|DERIVED     |t_position        |          |ALL   |t_position_login_IDX                    |                     |       |                                            |  65|   100.0|Using where; Using temporary|
     3|DERIVED     |underlying_manager|          |eq_ref|UnderlyingCode_UNIQUE                   |UnderlyingCode_UNIQUE|302    |ezytrs.t_position.symbol                    |   1|   100.0|Using where                 |
     3|DERIVED     |variety           |          |eq_ref|PRIMARY                                 |PRIMARY              |4      |中金_ylcms.underlying_manager.UnderlyingTypeId|   1|   100.0|Using index                 |
     4|DERIVED     |t_deal            |          |ALL   |t_deal_login_IDX,t_deal_action_IDX      |                     |       |                                            | 166|   65.06|Using where; Using temporary|
     4|DERIVED     |<derived5>        |          |ref   |<auto_key0>                             |<auto_key0>          |152    |ezytrs.t_deal.login                         |  10|   100.0|                            |
     5|DERIVED     |t_entrust         |          |ALL   |t_entrust_login_IDX,t_entrust_action_IDX|                     |       |                                            | 264|   65.53|Using where; Using temporary|
     5|DERIVED     |<subquery6>       |          |eq_ref|<auto_distinct_key>                     |<auto_distinct_key>  |5      |ezytrs.t_entrust.entrust                    |   1|   100.0|Using where; Not exists     |
     6|MATERIALIZED|t_deal            |          |index |t_deal_entrust_IDX                      |t_deal_entrust_IDX   |4      |                                            | 166|   100.0|Using index                 |
    
    ecloud
        1
    ecloud  
    OP
       2022-02-23 14:21:38 +08:00
    建立了联合索引,也没发现任何改变,是不是 mysql 引擎认为建立 temp 表速度更优?
    liprais
        2
    liprais  
       2022-02-23 14:44:48 +08:00
    optimizer trace 呗
    swcat
        3
    swcat  
       2022-02-23 14:59:00 +08:00
    set session optimizer_trace="enabled=on", end_markers_in_json=on;

    你的 sql

    SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE limit 30;
    ecloud
        4
    ecloud  
    OP
       2022-02-23 15:38:23 +08:00
    @swcat {¶ "steps": [¶ ] /* steps */¶}
    除了这个就没东西了...
    ecloud
        5
    ecloud  
    OP
       2022-02-23 15:48:55 +08:00
    @swcat 加了几个参数,搞出来了,在看
    ecloud
        6
    ecloud  
    OP
       2022-02-23 16:15:14 +08:00
    看了一下 optimizer ,其他几个都懂,引擎依据 cost 选择了 temp 表

    唯独这个

    ···
    "considered_execution_plans": [
    {
    "plan_prefix": [
    ] /* plan_prefix */,
    "table": "`t_deal`",
    "best_access_path": {
    "considered_access_paths": [
    {
    "access_type": "ref",
    "index": "t_deal_entrust_IDX",
    "usable": false,
    "chosen": false
    },
    {
    "rows_to_scan": 166,
    "access_type": "scan",
    "resulting_rows": 166,
    "cost": 17.6,
    "chosen": true
    }
    ] /* considered_access_paths */
    } /* best_access_path */,
    "condition_filtering_pct": 100,
    "rows_for_plan": 166,
    "cost_for_plan": 17.6,
    "sort_cost": 166,
    "new_cost_for_plan": 183.6,
    "chosen": true
    }
    ···

    为啥 useable 是 false ? cost_for_plan 和 new_cost_for_plan 分别表示啥?
    swcat
        7
    swcat  
       2022-02-25 10:17:05 +08:00
    俗称就是禁用索引来提高性能
    你觉得它选择错误可以使用 force index 来纠正它的选择
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   852 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 19:30 · PVG 03:30 · LAX 12:30 · JFK 15:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.