精华内容
下载资源
问答
  • MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。如果简单来理解,就是优化器会尽可能的把index condition的处理从Server层下推到存储...

    自MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。

    ab11da02356211f36a81adf2f38fd752.png

    如果简单来理解,就是优化器会尽可能的把index condition的处理从Server层下推到存储引擎层。举一个例子,有一个表中含有组合索引idx_cols包含(c1,c2,…,cn)n个列,如果在c1上存在范围扫描的where条件,那么剩余的c2,…,cn这n-1个上索引都无法用来提取和过滤数据,而ICP就是把这个事情优化一下。

    我们在MySQL 5.6的环境中来简单测试一下。

    我们创建表emp,含有一个主键,一个组合索引来说明一下。

    createtableemp(

    empno smallint(5) unsignednotnullauto_increment,

    ename varchar(30)notnull,

    deptno smallint(5) unsignednotnull,

    job varchar(30)notnull,

    primarykey(empno),

    keyidx_emp_info(deptno,ename)

    )engine=InnoDB charset=utf8;

    当然我也随机插入了几条数据,意思一下。

    insertintoempvalues(1,'zhangsan',1,'CEO'),(2,'lisi',2,'CFO'),(3,'wangwu',3,'CTO'),(4,'jeanron100',3,'Enginer');

    ICP的控制在数据库参数中有一个优化器参数optimizer_switch来统一管理,我想这也是MySQL优化器离我们最贴近的时候了。可以使用如下的方式来查看。

    show variableslike'optimizer_switch';

    当然在5.6以前的版本中,你是看不到index condition pushdown这样的字样的。在5.6版本中查看到的结果如下:

    # mysqladmin var|grep optimizer_switch optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on下面我们就用两个语句来对比说明一下,就通过执行计划来对比。

    setoptimizer_switch ="index_condition_pushdown=off"

    > explain select*fromempwheredeptnobetween1and100andename ='jeanron100';

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    | id | select_type | table| type | possible_keys |key| key_len | ref  |rows| Extra      |

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    |  1 | SIMPLE      | emp  | ALL| idx_emp_info  |NULL|NULL|NULL|    4 | Usingwhere|

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    而如果开启,看看ICP是否启用。

    setoptimizer_switch ="index_condition_pushdown=on";> explainselect*fromempwheredeptnobetween10and3000andename ='jeanron100';

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    | id | select_type | table| type  | possible_keys |key| key_len | ref  |rows| Extra                |

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    |  1 | SIMPLE      | emp  | range | idx_emp_info  | idx_emp_info | 94      | NULL|    1 | Usingindexcondition |

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    1 row in set (0.00 sec)如果你观察仔细,会发现两次的语句还是不同的,那就是范围扫描的范围不同,如果还是用原来的语句,结果还是有一定的限制的。

    > explainselect*fromempwheredeptnobetween1and300andename ='jeanron100';

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    | id | select_type | table| type | possible_keys |key| key_len | ref  |rows| Extra      |

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    |  1 | SIMPLE      | emp  | ALL| idx_emp_info  |NULL|NULL|NULL|    4 | Usingwhere|

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    1 row in set (0.00 sec)这个地方就值得好好推敲了。

    【编辑推荐】

    【责任编辑:武晓燕 TEL:(010)68476606】

    点赞 0

    展开全文
  • 一 什么是“索引条件下推”“索引条件下推”,称为Index Condition Pushdown (ICP),这是MySQL提供的用某一个索引对一个特定的表从表中获取元组”,注意我们这里特意强调了“一个”,这是因为这样的索引优化不是用于...

    一 什么是“索引条件下推”

    “索引条件下推”,称为Index Condition Pushdown (ICP),这是MySQL提供的用某一个索引对一个特定的表从表中获取元组”,注意我们这里特意强调了“一个”,这是因为这样的索引优化不是用于多表连接而是用于单表扫描,确切地说,是单表利用索引进行扫描以获取

    二 “索引条件下推”的目的

    用ySQL官方手册描述:

    The goal of ICP is to reduce the number of full-record reads and thereby reduce IO operations. For InnoDB clustered indexes, the complete record is already read into the InnoDB buffer. Using ICP in this case does not reduce IO.

    这句官方描述,一是说明减少完整记录(一条完整元组)读取的个数;二是说明对于InnoDB聚集索引无效,只能是对SECOND INDEX这样的非聚集索引有效。

    三 原理

    先看//关闭ICP

    Query OK, 0 rows affected (0.00 sec)

    myrange | a4_i | a4_i | 28 | NULL | 1 | 100.00 | Using where|

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+

    1 row in set, 1 warning (0.00 sec)

    mysql> set optimizer_switch='index_condition_pushdown=on'; //打开ICP,则Extra列中显示“Using index condition”

    Query OK, 0 rows affected (0.00 sec)

    mysql> EXPLAIN SELECT * FROM t4 WHERE 1=t4.a4 AND t4.name like 'char%';

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+

    | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+

    | 1 | SIMPLE | t4 | NULL | range | a4_i | a4_i | 28| NULL | 1 | 100.00 | Using index condition|

    +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-----------------------+

    1 row in set, 1 warning (0.00 sec)

    如果打开ICP,则执行计划的Extra列会显示“Using index condition”,这表明在。

    借用网上的2张图加以改造,并配以解释,来说明原理,更清晰地说明问题。

    图一:不使用ICP技术(过程使用数字符号标示,如①②③等) 过程解释:

    ①:My

    if (in_first_read)

    {

    in_first_read= false;

    error= (*qep_tab->read_first_record)(qep_tab); //设定合适的读取函数,如设定索引读函数/全表扫描函数

    }

    else

    error= info->read_record(info);

    ②、③:进入存储引擎,读取索引树,在索引树上查找,把满足条件的(经过查找,红色的满足)从表记录中读出(步骤④,通常有IO),从存储引擎返回⑤标识的结果。此处,不仅要在索引行进行索引读取(通常是内存中,速度快。步骤③),还要进行进行步骤④,通常有IO。

    ⑥:从存储引擎返回查找到的多条元组给MySQL Server,MySQL Server在⑦得到较多的元组。

    ⑦--⑧:⑦到⑧依据WHERE子句条件进行过滤,得到满足条件的元组。注意在MySQL Server层得到较多元组,然后才过滤,最终得到的是少量的、符合条件的元组。图二:使用ICP技术(过程使用数字符号标示,如①②③等)

    80bcb30fcbb26bd1dc50a9a422e3bbf5.png过程解释:

    ①:MySQL Server发出读取数据的命令,过程同图一。

    ②、③:进入存储引擎,读取索引树,在索引树上查找,把满足 已经下推的条件 的(经过查找,红色的满足)从表记录中读出(步骤④,通常有IO),从存储引擎返回⑤标识的结果。此处, 不仅要在索引行进行索引读取(通常是内存中,速度快。步骤③),还要在 ③这个阶段依据下推的条件 进行进行判断,不满足条件的,不去读取表中的数据,直接在索引树上进行下一个索引项的判断,直到有满足条件的,才进行步骤④,这样,较没有ICP的方式,IO量减少。

    ⑥:从存储引擎返回查找到的少量元组给MySQL Server,MySQL Server在⑦得到少量的元组。因此比较图一无ICP的方式,返回给MySQL Server层的即是少量的、符合条件的元组。

    另外,图中的部件层次关系,不再进行解释。

    四 实现细节

    1 ICP只能用于辅助索引,不能用于聚集索引。

    2 ICP只用于单表,不是多表连接是的连接条件部分(如开篇强调)

    如果表访问的类型为:

    3 EQ_REF/REF_OR_NULL/REF/SYSTEM/CONST: 可以使用ICP

    4 range:如果不是“index tree only(只读索引)”,则有机会使用ICP

    5 ALL/FT/INDEX_MERGE/INDEX_SCAN: 不可以使用ICP

    五 上楼

    1 条件下推,一直是SQL优化的基本规则。所以,条件下推技术是常规技术。

    2 技术层面,MySQL存在MySQL Server层和储存层,使得条件下推显得“有些割裂”。

    3 非技术层面,MySQL之所以引入ICP,猜一猜或拍拍脑袋,原因你懂得。

    六 从代码的角度看

    对于图一的解释,给出了读数据的代码片段,无论是关闭还是打开ICP, 从下面给出的函数调用关系可以看出,2幅图对应的情况下,代码路径是一致的.

    首条元组读取调用关系(蓝色标识和非首条元组不同之处):

    JOIN::exec()->do_select()->sub_select()->join_init_read_record()->rr_quick()->

    Q

    DsMrr_impl::dsmrr_next()->handler::multi_range_read_next()->

    handler::read_range_first()->handler::ha_index_read_

    handler::index_read_map()->ha_innobase::index_read()

    除首条元组读取调用关系(蓝色标识和首条元组不同之处)

    JOIN::exec()->do_select()->sub_select()->join_init_read_record()->rr_quick()->

    QUICK_RANGE_SELECT::get_next()->ha_innobase::multi_range_read_next()->

    DsMrr_impl::dsmrr_next()->handler::multi_range_read_next()->

    handler::read_range_next()->handler::ha_index_next()->

    ha_innobase::index_next()->ha_innobase::general_fetch()

    展开全文
  • MySQL的ICP技术的使用条件Index Condition Pushdown (ICP) ,是索引条件下推,是MySQL利用索引快速获取数据的技术。只要在查询语句中,使用了WHERE子句,且子句中有存在索引的条件表达式,比如a>3且列上存在索引,则...

    MySQL的ICP技术的使用条件

    Index Condition Pushdown (ICP) ,是索引条件下推,是MySQL利用索引快速获取数据的技术。

    只要在查询语句中,使用了WHERE子句,且子句中有存在索引的条件表达式,比如a>3且列上存在索引,则可能使用ICP技术对读取数据进行优化。这个技术不区分存储引擎,各个类型的存储引擎都可以使用。

    但是,有的时候,ICP可以被使用,有的时候却不能被使用,原因是什么?

    例如:

    CREATE TABLE `t1` (

    `a` int(11) NOT NULL,

    `b` int(11) NOT NULL,

    `c` int(11) NOT NULL,

    `d` int(11) NOT NULL,

    `e` int(11) NOT NULL,

    PRIMARY KEY (`a` DESC,`b`),

    KEY `c_DESC_d_DESC` (`c` DESC,`d` DESC)

    ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

    CREATE TABLE `t2` (

    `a` int(11) NOT NULL,

    `b` int(11) NOT NULL,

    `c` int(11) NOT NULL,

    `d` int(11) NOT NULL,

    `e` int(11) NOT NULL,

    PRIMARY KEY (`a` DESC,`b`),

    KEY `c_DESC_d_DESC` (`c` DESC,`d` DESC)

    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

    插入语句:

    INSERT INTO t1 VALUES (1, 1, 1, 2, 1);

    INSERT INTO t1 VALUES (1, 2, 1, 1, 2);

    INSERT INTO t1 VALUES (1, 3, 3, 2, 3);

    INSERT INTO t1 VALUES (5, 1, 3, 5, 4);

    INSERT INTO t1 VALUES (5, 2, 5, 5, 5);

    INSERT INTO t1 VALUES (5, 3, 6, 6, 6);

    INSERT INTO t1 VALUES (10, 1, 7, 9, 7);

    INSERT INTO t1 VALUES (11, 2, 7, 8, 8);

    INSERT INTO t1 VALUES (12, 3, 9, 9, 9);

    ANALYZE TABLE t1;

    INSERT INTO t2 VALUES (1, 1, 1, 2, 1);

    INSERT INTO t2 VALUES (1, 2, 1, 1, 2);

    INSERT INTO t2 VALUES (1, 3, 3, 2, 3);

    INSERT INTO t2 VALUES (5, 1, 3, 5, 4);

    INSERT INTO t2 VALUES (5, 2, 5, 5, 5);

    INSERT INTO t2 VALUES (5, 3, 6, 6, 6);

    INSERT INTO t2 VALUES (10, 1, 7, 9, 7);

    INSERT INTO t2 VALUES (11, 2, 7, 8, 8);

    INSERT INTO t2 VALUES (12, 3, 9, 9, 9);

    ANALYZE TABLE t2;

    同样的SQL语句,在不同的表上执行,查看并比较执行计划:

    对于t1表:

    mysql> EXPLAIN SELECT * FROM t1 WHERE a>3 ORDER BY a ASC, b ASC;

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------------+

    | id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra                       |

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------------+

    |  1 | SIMPLE      | t1    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |    3 |   100.00 | Using where; Using filesort |

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-----------------------------+

    1 row in set, 1 warning (0.00 sec)表t1的查询执行计划,没有使用ICP。

    对于t2表:

    mysql> EXPLAIN SELECT * FROM t2 WHERE a>3 ORDER BY a ASC, b ASC;

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+

    | id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra                                 |

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+

    |  1 | SIMPLE      | t2    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |    4 |   100.00 | Using index condition; Using filesort |

    +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+---------------------------------------+

    1 row in set, 1 warning (0.00 sec)表t2的查询执行计划,使用了ICP。为什么t1却没有使用ICP呢?

    ICP能被使用。这点可以通过类似如下的调用关系分析得知(此处举例使用了MyISAM引擎,InnoDB等与此类似)。

    optimize()-->make_join_readinfo-->push_index_cond()-->ha_myisam::idx_cond_push(unsigned int keyno_arg, Item * idx_cond_arg)

    在push_index_cond()函数中,规定了什么情况可以使用ICP,什么不可以使用ICP。

    可以使用ICP的情况如下:

    1 表带有WHERE子句,且

    2 存储引擎支持ICP,且

    3 系统参数

    index_condition_pushdown

    被打开,且

    4 查询不是针对多表的update或delete操作,且

    5 查询也不是子查询,且

    6 查询的表不是常量表(如果是常量表因记录数最多为1则没有必要使用ICP),且

    7 索引不是聚集索引(如果是InnoDB的主键索引,则是聚集索引,此类索引的查询速度快,也不需要执行ICP以获取ICP能带来的好处)

    至此,我们可以明白,为什么表t1没有使用ICP而表t2使用了ICP。

    仔细查看表t1的定义,列a上定义的索引是主键索引。所以表t1没有使用ICP。

    展开全文
  • MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。如果简单来理解,就是优化器会尽可能的把index condition的处理从Server层下推到存储...

    自MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。

    如果简单来理解,就是优化器会尽可能的把index condition的处理从Server层下推到存储引擎层。举一个例子,有一个表中含有组合索引idx_cols包含(c1,c2,…,cn)n个列,如果在c1上存在范围扫描的where条件,那么剩余的c2,…,cn这n-1个上索引都无法用来提取和过滤数据,而ICP就是把这个事情优化一下。

    我们在MySQL 5.6的环境中来简单测试一下。

    我们创建表emp,含有一个主键,一个组合索引来说明一下。

    create table emp(

    empno smallint(5) unsigned not null auto_increment,

    ename varchar(30) not null,

    deptno smallint(5) unsigned not null,

    job varchar(30) not null,

    primary key(empno),

    key idx_emp_info(deptno,ename)

    )engine=InnoDB charset=utf8;

    当然我也随机插入了几条数据,意思一下。

    insert into emp values(1,'zhangsan',1,'CEO'),(2,'lisi',2,'CFO'),(3,'wangwu',3,'CTO'),(4,'jeanron100',3,'Enginer');

    ICP的控制在数据库参数中有一个优化器参数optimizer_switch来统一管理,我想这也是MySQL优化器离我们最贴近的时候了。可以使用如下的方式来查看。

    show variables like 'optimizer_switch';

    当然在5.6以前的版本中,你是看不到index condition pushdown这样的字样的。在5.6版本中查看到的结果如下:

    # mysqladmin var|grep optimizer_switch optimizer_switch                                       | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on下面我们就用两个语句来对比说明一下,就通过执行计划来对比。

    set optimizer_switch = "index_condition_pushdown=off"

    > explain select  *   from emp  where deptno between 1 and 100 and ename ='jeanron100';

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    |  1 | SIMPLE      | emp   | ALL  | idx_emp_info  | NULL | NULL    | NULL |    4 | Using where |

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    而如果开启,看看ICP是否启用。

    set optimizer_switch = "index_condition_pushdown=on";> explain select  *   from emp  where deptno between 10 and 3000 and ename ='jeanron100';

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    | id | select_type | table | type  | possible_keys | key          | key_len | ref  | rows | Extra                 |

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    |  1 | SIMPLE      | emp   | range | idx_emp_info  | idx_emp_info | 94      | NULL |    1 | Using index condition |

    +----+-------------+-------+-------+---------------+--------------+---------+------+------+-----------------------+

    1 row in set (0.00 sec)如果你观察仔细,会发现两次的语句还是不同的,那就是范围扫描的范围不同,如果还是用原来的语句,结果还是有一定的限制的。

    > explain select  *   from emp  where deptno between 1 and 300 and ename ='jeanron100';

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    | id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    |  1 | SIMPLE      | emp   | ALL  | idx_emp_info  | NULL | NULL    | NULL |    4 | Using where|

    +----+-------------+-------+------+---------------+------+---------+------+------+-------------+

    1 row in set (0.00 sec)这个地方就值得好好推敲了。

    展开全文
  • MySQL 索引条件下推 Index Condition Pushdown 出现在MySQL5.6及之后的版本中,能大幅提升查询效率,原因如下:内容摘录自《深入理解MariaDB和MySQL》下面使实验,使用官方提供的employees 测试数据库演示。...
  • MySQL 5.6开始,在索引方面有了一些改进,比如索引条件下推(Index condition pushdown,ICP),严格来说属于优化器层面的改进。如果简单来理解,就是优化器会尽可能的把indexcondition的处理从Server层下推到存储引擎...
  • ICP 优化适用于 MySQL 利用索引从表里检索数据的场景。ICP 适用的场景ICP 用于访问方法是 range/ref/eq_ref/ref_or_null,且需要访问表的完整行记录。ICP适用于 InnoDB 和 MyISAM 的表,包括分区的表。对于 InnoDB ...
  • 索引条件下推(ICP)是对MySQL使用索引从表中检索行的情况的优化。如果没有ICP,存储引擎会遍历索引以查找基表中的行,并将它们返回给MySQL服务器,由server层再做一波筛选。启用ICP后,如果只使用索引中的列来评估...
  • MySQL中的索引下推

    2021-02-03 03:17:31
    前段时间看了一下数据库相关知识,出现了索引下推这个名词,有必要记录下来作为知识储备。索引下推用一句话总结是:索引下推是数据库检索数据过程中为减少回表次数而做的优化。首先介绍什么是数据库回表,回表是一...
  • Mysql 索引下推

    2021-04-16 17:19:52
    导读 索引下推(index ... 在使用ICP的情况,如果存在某些被索引的列的判断条件时,MySQL服务器将这一部分判断条件传递给存储引擎,然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件,只有当索引...
  • mysql这里说的是在使用索引查询时有关索引下推的有关知识点。sql综合前人的经验结果:索引下推是数据库检索数据过程当中为减小回表次数而作的优化。docker判断是否须要回表的是由mysql存储引擎控制,默认从mysql5.6...
  • 5.6之后,MySQL的优化技术在使用二级索引过滤where条件时,减少回表的次数 以及 MySQL server层和引擎层交互的次数1.数据库如何处理where条件index key(index first key index last key)确定sql查询在索引中的连续...
  • 问题一:要回答这个问题,就得先了解一下Mysql的执行流程,贴一下我之前的一...因此,在查询过程中,最重要的一部分是根据查询的SQL语句,依据多种索引,计算查询需要的代价,从而选择最优的索引方式生成查询计划。...
  • 在之前《mysql索引初识》这篇文章中提到过,mysql的innodb引擎通过搜索树方式实现索引,索引类型分为主键索引和二级索引(非主键索引),主键索引树中,叶子结点保存着主键即对应行的全部数据;而二级索引树中,叶子...
  • 1、索引下推mysql5.6(包括)之后的优化策略。 2、是否设置了索引下推,explain执行计划查看到了 rows 行数应该是一致的。因为索引下推只是减少了回表的次数。 打开索引下推。 set optimizer_switch='index_...
  • 一 什么是“索引条件下推”“索引条件下推”,称为Index Condition Pushdown (ICP),这是MySQL提供的用某一个索引对一个特定的表从表中获取元组”,注意我们这里特意强调了“一个”,这是因为这样的索引优化不是用于...
  • 5分钟搞懂MySQL - 索引下推优化

    千次阅读 多人点赞 2021-03-16 01:23:52
    对于长期与MySQL同流合污的朋友们来说,或许,“索引下推优化”这个词并不陌生,嗯。。经常听到,但是MySQL的这个“优化”到底优化了啥?就懵懵懂懂了,反正不是公司优化我就行了是吧。。来,让我们继续快乐的卷下去...
  • 索引条件下推,Index Condition Pushdown,简称ICP,是MySQL内部通过索引查询数据的一种优化方法,简单来说就是将原本需要在Server层对数据进行过滤的条件下推到了引擎层去做,在引擎层过滤更多的数据,这样从引擎层...
  • InnoDB首先会使用主键创建一个主键B+树索引和数据文件,此外还会通过联合索引(b,c,d)生成一个索引树,同样是B+树的结构,只不过它的data部分存储的是联合索引所在行的主键值(上图叶子节点紫色背景部分),这里...
  • 导读 ... 在使用ICP的情况,如果存在某些被索引的列的判断条件时,MySQL服务器将这一部分判断条件传递给存储引擎,然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件,只有当索引符合条
  • 五分钟搞懂MySQL索引下推

    千次阅读 2021-09-09 13:01:26
    面试时候问到索引,常常会顺嘴问一句索引下推。给我五分钟,图文并茂,带你get索引下推
  • 索引条件下推(ICP)是针对MySQL使用索引从表中检索行的情况的一种优化。如果不使用ICP,则存储引擎将遍历索引以在基表中定位行,并将其返回给MySQL服务器,后者将评估WHERE行的条件。启用ICP后,如果WHERE可以仅使用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 18,906
精华内容 7,562
关键字:

mysql索引条件下推

mysql 订阅