1.1 问题描述

  执行计划的不同肯定会带来效率的不同，但是在本例中执行计划完全一致，都是全表扫描，不同的只有字段个数而已。其次，测试中都使用了where条件进行过滤（Using where），过滤后没有数据返回，常说的where过滤实际上是在server层，当然某些情况下使用ICP会提前在Innodb层过滤数据，这里不考虑ICP。
对于大数据量访问来讲可能涉及到物理IO，首次访问和随后的访问因为Innodb buffer的关系，效率不同是正常，需要多测试几次。



通过上面的测试，可以发现随着字段的不断减少，效率越来越高，并且主要的区别都在sending data下面。简单的说Innodb数据的获取和Innodb数据到server层数据的传递都包含在其中。

2.2 理论依据

https://dev.mysql.com/doc/dev/mysql-server/latest/

全表访问数据的流程

  这里将简单描述一下这种全表扫描的流程，实际上其中有一个核心接口就是row_search_mvcc，它大概包含了如下功能：

• 通过预取缓存获取数据
• 打开事务
• 定位索引位置（包含使用AHI快速定位）
• 是否开启readview
• 通过持久化游标不断访问下一条数据
• 加Innodb表锁、加Innodb行锁
• 可见性判断
• 根据主键回表（可能回表需要加行锁）
• ICP优化
• SEMI update优化

  下面对MySQL处理字段多少时的优化流程做出介绍：

1、通过select字段构建read_set(server 层)

  首先需要构建一个叫做read_set的位图，来表示访问的字段位置及数量。

2、初次访问定位的时候还会构建一个模板（mysql_row_templ_t）(innodb 层)

  本模板主要用于当Innodb层数据到server层做转换的时候使用，其中记录了使用的字段数量、字段的字符集、字段的类型等等。

3、初次定位数据，定位游标到主键索引的第一行记录，为全表扫描做好准备（innodb层）

  对于这种全表扫描的执行方式，定位数据就变得简单了，只需要找到主键索引的第一条数据就好了。对于全表扫描的初次定位调用函数为btr_cur_open_at_index_side_fun。

  btr_cur_open_at_index_side_func的功能就是通过B+树结构，定位叶子结点的开头第一个块，然后调用函数page_cur_set_before_first，将游标放到了所有记录的开头，目的只有一个为全表扫描做好准备。

4、获取Innodb层的第一条数据（Innodb层）

  拿到了游标过后就可以获取数据了。但是这里获取的数据只是一个指针，言外之意可以理解为整行数据，其格式也是原始的Innodb数据，其中还包含了一些伪列比如（rollback ptr和trx id）。这里实际上和访问的字段个数无关。

5、将第一行记录转换为MySQL格式（Innodb层）

  这一步完成后可以认为记录已经返回给了server层，这里就是实际的数据拷贝了，并不是指针，整个过程放到了函数row_sel_store_mysql_rec中。

  前面的模板（mysql_row_templ_t）也会在这里发挥它的作用，这是一个字段过滤的过程，先来看一个循环
for (i = 0; i < prebuilt->n_template; i++)，其中prebuilt->n_template就是字段模板的个数，通过read_set的过滤，对于不需要的字段是不会建立模板的。因此这里的模板数量是和访问的字段个数一样的。

  然后在这个循环下面会调用row_sel_store_mysql_field_func然后调用row_sel_field_store_in_mysql_format_func将字段一个一个转换为MySQL的格式。其中一种类型的转换如下：

    case DATA_INT:/* Convert integer data from Innobase to a little-endianformat, sign bit restored to normal */ptr = dest + len;for (;;) {ptr--;*ptr = *data;//值拷贝 内存拷贝if (ptr == dest) {break;}data++;}

  可以发现这是一种实际的转换，也就是需要花费内存空间的。查询的字段越多那么着这里转换的过程越长，并且这里都是实际的内存拷贝,最终这行数据会存储到row_search_mvcc的形参buffer中返回给server层。

6、对第一条数据进行where过滤（server层）

  拿到数据后当然还不能作为最终的结果返回给用户，需要在server层做一个过滤操作，这个条件比较位于函数evaluate_join_record的开头。

  如果和条件不匹配将会返回False。这里比较会最终调用Item_func的各种方法，如果等于则是Item_func_eq。

7、访问下一条数据(server 层)

  上面已经展示了访问第一条数据的大体流程，接下面需要做的就是继续访问下去，如下：

移动游标到下一行
访问数据
根据模板转换数据返回给server层
根据where条件过滤

  整个过程会持续到全部主键索引数据访问完成。

  并且row_search_mvcc的流程肯定也会有变化。但是实际的获取数据转换过程和过滤过程并没有改变。注意这些步骤除了步骤1，基本都处于sending data下面。

  到这里已经大概知道全表扫描的访问数据的流程了，就来看看一下在全表扫描流程中字段的多少到底有哪些异同点：

不同点

• 构建的read_set不同，字段越多read_set中为‘1’的位数越多
• 建立的模板不同，字段越多模板数量越多
• 每行数据转换为MySQL格式的时候不同，字段越多模板越多，那么循环转换每个字段的循环次数也就越多，并且这是每行都要处理的。返回给server层的行内存消耗越大。

相同点

• 访问的行数一致
• 访问的流程一致
• where过滤的方式一致

  在整个不同点中，认为最耗时的部分应该是每行数据转换为MySQL格式的消耗最大，因为每行每个字段都需要做这样的转换，这也刚好是除以sending data状态下面。线上大于10个字段的表比比皆是，如果只需要访问其中的少量字段，最好还是写实际的字段而不是‘*’，来规避这个问题。

总结
本文中以全表扫描为列进行了解释，但是实际上任何情况下都应该缩减访问字段的数量，应该只访问需要的字段。