MySQL中查詢字段數(shù)量多少會(huì)對(duì)查詢效率有影響

這篇文章將為大家詳細(xì)講解有關(guān)MySQL中查詢字段數(shù)量多少會(huì)對(duì)查詢效率有影響，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),煙臺(tái)企業(yè)網(wǎng)站建設(shè),煙臺(tái)品牌網(wǎng)站建設(shè),網(wǎng)站定制,煙臺(tái)網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,煙臺(tái)網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

一、問(wèn)題由來(lái)

我們知道執(zhí)行計(jì)劃的不同肯定會(huì)帶來(lái)效率的不同，但是在本例中執(zhí)行計(jì)劃完全一致，都是全表掃描，不同的只有字段個(gè)數(shù)而已。其次，測(cè)試中都使用了where條件進(jìn)行過(guò)濾（Using where），過(guò)濾后沒(méi)有數(shù)據(jù)返回，我們常說(shuō)的where過(guò)濾實(shí)際上是在MySQL層，當(dāng)然某些情況下使用ICP會(huì)提前在Innodb層過(guò)濾數(shù)據(jù)，這里我們先不考慮ICP，我會(huì)在后面的文章中詳細(xì)描述ICP的流程，本文也會(huì)給出where過(guò)濾的接口，供大家參考。

下面的截圖來(lái)自兩個(gè)朋友，感謝他們的測(cè)試和問(wèn)題提出。另外對(duì)于大數(shù)據(jù)量訪問(wèn)來(lái)講可能涉及到物理IO，首次訪問(wèn)和隨后的訪問(wèn)因?yàn)镮nnodb buffer的關(guān)系，效率不同是正常，需要多測(cè)試幾次。

測(cè)試1：

測(cè)試2：

我們通過(guò)這兩個(gè)測(cè)試，可以發(fā)現(xiàn)隨著字段的不斷減少，效率越來(lái)越高，并且主要的區(qū)別都在sending data 下面，這個(gè)狀態(tài)我曾經(jīng)大概描述過(guò)參考文章：
https://www.jianshu.com/p/46ad0aaf7ed7
https://www.jianshu.com/p/4cdec711adef

簡(jiǎn)單的說(shuō)Innodb數(shù)據(jù)的獲取和Innodb數(shù)據(jù)到MySQL層數(shù)據(jù)的傳遞都包含在其中。

二、簡(jiǎn)單的流程介紹

下面我主要結(jié)合字段多少和全表掃描2個(gè)方面做一個(gè)簡(jiǎn)單的流程介紹。實(shí)際上其中有一個(gè)核心接口就是row_search_mvcc，它大概包含了如下功能：

• 通過(guò)預(yù)取緩存獲取數(shù)據(jù)

• 打開事務(wù)

• 定位索引位置（包含使用AHI快速定位）

• 是否開啟readview

• 通過(guò)持久化游標(biāo)不斷訪問(wèn)下一條數(shù)據(jù)

• 加Innodb表鎖、加Innodb行鎖

• 可見(jiàn)性判斷

• 根據(jù)主鍵回表（可能回表需要加行鎖）

• ICP優(yōu)化

• SEMI update優(yōu)化

并且作為訪問(wèn)數(shù)據(jù)的必須經(jīng)歷的接口，這個(gè)函數(shù)也是很值得大家細(xì)細(xì)研讀的。

1. 通過(guò)select字段構(gòu)建read_set（MySQL層）

首先需要構(gòu)建一個(gè)叫做read_set的位圖，來(lái)表示訪問(wèn)的字段位置及數(shù)量。它和write set一起，在記錄binlog的Event的時(shí)候也會(huì)起著重要作用，可以參考我的《深入理解MySQL主從原理》中關(guān)于binlog_row_image參數(shù)一節(jié)。這里構(gòu)建的主要接口為TABLE::mark_column_used函數(shù)，每個(gè)需要訪問(wèn)的字段都會(huì)調(diào)用它來(lái)設(shè)置自己的位圖。下面是其中的一段如下：

case MARK_COLUMNS_READ:
    bitmap_set_bit(read_set, field->field_index);

從棧幀來(lái)看這個(gè)構(gòu)建read_set的過(guò)程位于狀態(tài)‘init’下面。棧幀見(jiàn)結(jié)尾棧幀1。

2. 初次訪問(wèn)定位的時(shí)候還會(huì)構(gòu)建一個(gè)模板（mysql_row_templ_t）（Innodb層）

本模板主要用于當(dāng)Innodb層數(shù)據(jù)到MySQL層做轉(zhuǎn)換的時(shí)候使用，其中記錄了使用的字段數(shù)量、字段的字符集、字段的類型等等。接口build_template_field用于構(gòu)建這個(gè)模板。棧幀見(jiàn)結(jié)尾棧幀2。
但是需要注意的是，這里構(gòu)建模板就會(huì)通過(guò)我們上面說(shuō)的read_set去判斷到底有多少字段需要構(gòu)建到模板中，然后才會(huì)調(diào)用build_template_field函數(shù)。如下是最重要的代碼，它位于build_template_needs_field接口中。

bitmap_is_set(table->read_set, static_cast<uint>(i)

可以看到這里正在測(cè)試本字段是否出現(xiàn)在了read_set中，如果不在則跳過(guò)這個(gè)字段。下面是函數(shù)build_template_needs_field的注釋：

Determines if a field is needed in a m_prebuilt struct 'template'.
@return field to use, or NULL if the field is not needed */

到這里我們需要訪問(wèn)的字段已經(jīng)確立下來(lái)了

3. 初次定位數(shù)據(jù)，定位游標(biāo)到主鍵索引的第一行記錄，為全表掃描做好準(zhǔn)備（Innodb層）

對(duì)于這種全表掃描的執(zhí)行方式，定位數(shù)據(jù)就變得簡(jiǎn)單了，我們只需要找到主鍵索引的第一條數(shù)據(jù)就好了，它和平時(shí)我們使用（ref/range）定位方式不同，不需要二分法的支持。因此對(duì)于全表掃描的初次定位調(diào)用函數(shù)為btr_cur_open_at_index_side_func，而不是通常我們說(shuō)的btr_pcur_open_with_no_init_func。
如果大概看一下函數(shù)btr_cur_open_at_index_side_func的功能，我們很容易看到，它就是通過(guò)B+樹結(jié)構(gòu)，定位到葉子結(jié)點(diǎn)的開頭第一個(gè)塊，然后調(diào)用函數(shù)page_cur_set_before_first，將游標(biāo)放到了所有記錄的開頭，目的只有一個(gè)為全表掃描做好準(zhǔn)備。棧幀見(jiàn)結(jié)尾棧幀3。
注意這里正是通過(guò)我們r(jià)ow_search_mvcc調(diào)用下去的。

4. 獲取Innodb層的第一條數(shù)據(jù)（Innodb層）

拿到了游標(biāo)過(guò)后就可以獲取數(shù)據(jù)了，這里也很簡(jiǎn)單代碼就是一句如下：

rec = btr_pcur_get_rec(pcur);//獲取記錄 從持久化游標(biāo)   整行數(shù)據(jù)

但是需要注意的是這里獲取的數(shù)據(jù)只是一個(gè)指針，言外之意可以理解為整行數(shù)據(jù)，其格式也是原始的Innodb數(shù)據(jù)，其中還包含了一些偽列比如（rollback ptr和trx id）。這里實(shí)際上和訪問(wèn)的字段個(gè)數(shù)無(wú)關(guān)。

5. 將第一行記錄轉(zhuǎn)換為MySQL格式（Innodb層）

這一步完成后我們可以認(rèn)為記錄已經(jīng)返回給了MySQL層，這里就是實(shí)際的數(shù)據(jù)拷貝了，并不是指針，整個(gè)過(guò)程放到了函數(shù)row_sel_store_mysql_rec中。
我們前面的模板（mysql_row_templ_t）也會(huì)在這里發(fā)揮它的作用，這是一個(gè)字段過(guò)濾的過(guò)程，我們先來(lái)看一個(gè)循環(huán)

for (i = 0; i < prebuilt->n_template; i++)

其中prebuilt->n_template就是字段模板的個(gè)數(shù)，我們前面已經(jīng)說(shuō)過(guò)了，通過(guò)read_set的過(guò)濾，對(duì)于我們不需要的字段是不會(huì)建立模板的。因此這里的模板數(shù)量是和我們?cè)L問(wèn)的字段個(gè)數(shù)一樣的。

然后在這個(gè)循環(huán)下面會(huì)調(diào)用row_sel_store_mysql_field_func然后調(diào)用row_sel_field_store_in_mysql_format_func將字段一個(gè)一個(gè)轉(zhuǎn)換為MySQL的格式。我們來(lái)看一下其中一種類型的轉(zhuǎn)換如下：

    case DATA_INT:
        /* Convert integer data from Innobase to a little-endian
        format, sign bit restored to normal */
        ptr = dest + len;
        for (;;) {
            ptr--;
            *ptr = *data;//值拷貝 內(nèi)存拷貝
            if (ptr == dest) {
                break;
            }
            data++;
        }

我們可以發(fā)現(xiàn)這是一種實(shí)際的轉(zhuǎn)換，也就是需要花費(fèi)內(nèi)存空間的。棧幀見(jiàn)結(jié)尾棧幀4。
到這里我們大概知道了，查詢的字段越多那么著這里轉(zhuǎn)換的過(guò)程越長(zhǎng)，并且這里都是實(shí)際的內(nèi)存拷貝

最終這行數(shù)據(jù)會(huì)存儲(chǔ)到row_search_mvcc的形參 buffer中返回給MySQL層，這個(gè)形參的注釋如下：

@param[out]    buf        buffer for the fetched row in MySQL format

6.對(duì)第一條數(shù)據(jù)進(jìn)行where過(guò)濾（MySQL層）

拿到數(shù)據(jù)后當(dāng)然還不能作為最終的結(jié)果返回給用戶，我們需要在MySQL層做一個(gè)過(guò)濾操作，這個(gè)條件比較位于函數(shù)evaluate_join_record的開頭，其中比較就是下面一句話

found= MY_TEST(condition->val_int()); //進(jìn)行比較 調(diào)用到 條件和 返回會(huì)記錄的比較

如果和條件不匹配將會(huì)返回False。這里比較會(huì)最終調(diào)用Item_func的各種方法，如果等于則是Item_func_eq，棧幀見(jiàn)結(jié)尾棧幀5。

7.訪問(wèn)下一條數(shù)據(jù)

上面我已經(jīng)展示了訪問(wèn)第一條數(shù)據(jù)的大體流程，接下面需要做的就是繼續(xù)訪問(wèn)下去，如下：

• 移動(dòng)游標(biāo)到下一行

• 訪問(wèn)數(shù)據(jù)

• 根據(jù)模板轉(zhuǎn)換數(shù)據(jù)返回給MySQL層

• 根據(jù)where條件過(guò)濾

整個(gè)過(guò)程會(huì)持續(xù)到全部主鍵索引數(shù)據(jù)訪問(wèn)完成。但是需要注意的是上層接口有些變化，由ha_innobase::index_first會(huì)變?yōu)閔a_innobase::rnd_next，統(tǒng)計(jì)數(shù)據(jù)由Handler_read_first變?yōu)镠andler_read_rnd_next，這點(diǎn)可以參考我的文章：
https://www.jianshu.com/p/25fed8f1f05e
并且row_search_mvcc的流程肯定也會(huì)有變化。這里不再熬述。但是實(shí)際的獲取數(shù)據(jù)轉(zhuǎn)換過(guò)程和過(guò)濾過(guò)程并沒(méi)有改變。

注意了這些步驟除了步驟1，基本都處于sending data下面。

三、回到問(wèn)題本身

好了到這里我們大概知道全表掃描的訪問(wèn)數(shù)據(jù)的流程了，我們就來(lái)看看一下在全表掃描流程中字段的多少到底有哪些異同點(diǎn)：

不同點(diǎn)：

• 構(gòu)建的read_set 不同，字段越多read_set中為‘1’的位數(shù)越多

• 建立的模板不同，字段越多模板數(shù)量越多

• 每行數(shù)據(jù)轉(zhuǎn)換為MySQL格式的時(shí)候不同，字段越多模板越多，那么循環(huán)轉(zhuǎn)換每個(gè)字段的循環(huán)次數(shù)也就越多，并且這是每行都要處理的。

• 返回給MySQL層的行內(nèi)存消耗越大

相同點(diǎn)：

• 訪問(wèn)的行數(shù)一致

• 訪問(wèn)的流程一致

• where過(guò)濾的方式一致

在整個(gè)不同點(diǎn)中，我認(rèn)為最耗時(shí)的部分應(yīng)該是每行數(shù)據(jù)轉(zhuǎn)換為MySQL格式的消耗最大，因?yàn)槊啃忻總€(gè)字段都需要做這樣的轉(zhuǎn)換，這也剛好是除以sending data狀態(tài)下面。我們線上大于10個(gè)字段的表比比皆是，如果我們只需要訪問(wèn)其中的少量字段，我們最好還是寫實(shí)際的字段而不是‘*’，來(lái)規(guī)避這個(gè)問(wèn)題。

四、寫在最后

雖然本文中以全表掃描為列進(jìn)行了解釋，但是實(shí)際上任何情況下我們都應(yīng)該縮減訪問(wèn)字段的數(shù)量，應(yīng)該只訪問(wèn)需要的字段。

五、備用棧幀

棧幀1 read_set構(gòu)建

#0  TABLE::mark_column_used (this=0x7ffe7c996c50, thd=0x7ffe7c000b70, field=0x7ffe7c997c88, mark=MARK_COLUMNS_READ)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/table.cc:6344
#1  0x00000000015449b4 in find_field_in_table_ref (thd=0x7ffe7c000b70, table_list=0x7ffe7c0071f0, name=0x7ffe7c006a38 "id", length=2, item_name=0x7ffe7c006a38 "id", 
    db_name=0x0, table_name=0x0, ref=0x7ffe7c006bc0, want_privilege=1, allow_rowid=true, cached_field_index_ptr=0x7ffe7c0071a0, register_tree_change=true, 
    actual_table=0x7fffec0f46d8) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_base.cc:7730
#2  0x0000000001544efc in find_field_in_tables (thd=0x7ffe7c000b70, item=0x7ffe7c0070c8, first_table=0x7ffe7c0071f0, last_table=0x0, ref=0x7ffe7c006bc0, 
    report_error=IGNORE_EXCEPT_NON_UNIQUE, want_privilege=1, register_tree_change=true) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_base.cc:7914
#3  0x0000000000faadd8 in Item_field::fix_fields (this=0x7ffe7c0070c8, thd=0x7ffe7c000b70, reference=0x7ffe7c006bc0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item.cc:5857
#4  0x00000000015478ee in setup_fields (thd=0x7ffe7c000b70, ref_pointer_array=..., fields=..., want_privilege=1, sum_func_list=0x7ffe7c005d90, allow_sum_func=true, 
    column_update=false) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_base.cc:9047
#5  0x000000000161419d in st_select_lex::prepare (this=0x7ffe7c005c30, thd=0x7ffe7c000b70) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_resolver.cc:190

棧幀2 構(gòu)建模板

#0  build_template_field (prebuilt=0x7ffe7c99b880, clust_index=0x7ffe7c999c20, index=0x7ffe7c999c20, table=0x7ffe7c996c50, field=0x7ffe7c997c88, i=0, v_no=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:7571
#1  0x00000000019d1dc1 in ha_innobase::build_template (this=0x7ffe7c997610, whole_row=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:8034
#2  0x00000000019d60f5 in ha_innobase::change_active_index (this=0x7ffe7c997610, keynr=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9805
#3  0x00000000019d682b in ha_innobase::rnd_init (this=0x7ffe7c997610, scan=true)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:10031
#4  0x0000000000f833b9 in handler::ha_rnd_init (this=0x7ffe7c997610, scan=true) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.cc:3096
#5  0x00000000014e24d1 in init_read_record (info=0x7ffe7cf47d60, thd=0x7ffe7c000b70, table=0x7ffe7c996c50, qep_tab=0x7ffe7cf47d10, use_record_cache=1, 
    print_error=true, disable_rr_cache=false) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/records.cc:315

棧幀3 全表掃描初次定位棧幀

#0  page_cur_set_before_first (block=0x7fff4d02f4a0, cur=0x7ffe7c99bab0) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/include/page0cur.ic:99
#1  0x0000000001c5187f in btr_cur_open_at_index_side_func (from_left=true, index=0x7ffe7c999c20, latch_mode=1, cursor=0x7ffe7c99baa8, level=0, 
    file=0x239d388 "/root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/include/btr0pcur.ic", line=562, mtr=0x7fffec0f3570)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/btr/btr0cur.cc:2422
#2  0x0000000001b6e9c9 in btr_pcur_open_at_index_side (from_left=true, index=0x7ffe7c999c20, latch_mode=1, pcur=0x7ffe7c99baa8, init_pcur=false, level=0, 
    mtr=0x7fffec0f3570) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/include/btr0pcur.ic:562
#3  0x0000000001b79a35 in row_search_mvcc (buf=0x7ffe7c997b50 "\377", mode=PAGE_CUR_G, prebuilt=0x7ffe7c99b880, match_mode=0, direction=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:5213
#4  0x00000000019d5493 in ha_innobase::index_read (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9536
#5  0x00000000019d66ea in ha_innobase::index_first (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9977
#6  0x00000000019d6934 in ha_innobase::rnd_next (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:10075
#7  0x0000000000f83725 in handler::ha_rnd_next (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.cc:3146
#8  0x00000000014e2b3d in rr_sequential (info=0x7ffe7cf47d60) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/records.cc:521

棧幀4 MySQL格式的轉(zhuǎn)換

#0  row_sel_field_store_in_mysql_format_func (dest=0x7ffe7c997b51 "", templ=0x7ffe7c9a27f8, index=0x7ffe7c999c20, field_no=0, data=0x7fff4daec0a1 "\200", len=4, 
    prebuilt=0x7ffe7c99b880, sec_field=18446744073709551615) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:2888
#1  0x0000000001b754b9 in row_sel_store_mysql_field_func (mysql_rec=0x7ffe7c997b50 "\377", prebuilt=0x7ffe7c99b880, rec=0x7fff4daec0a1 "\200", index=0x7ffe7c999c20, 
    offsets=0x7fffec0f3a80, field_no=0, templ=0x7ffe7c9a27f8, sec_field_no=18446744073709551615)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:3255
#2  0x0000000001b75c85 in row_sel_store_mysql_rec (mysql_rec=0x7ffe7c997b50 "\377", prebuilt=0x7ffe7c99b880, rec=0x7fff4daec0a1 "\200", vrow=0x0, rec_clust=0, 
    index=0x7ffe7c999c20, offsets=0x7fffec0f3a80, clust_templ_for_sec=false) at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:3434
#3  0x0000000001b7bd61 in row_search_mvcc (buf=0x7ffe7c997b50 "\377", mode=PAGE_CUR_G, prebuilt=0x7ffe7c99b880, match_mode=0, direction=0)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/row/row0sel.cc:6123
#4  0x00000000019d5493 in ha_innobase::index_read (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9536
#5  0x00000000019d66ea in ha_innobase::index_first (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:9977
#6  0x00000000019d6934 in ha_innobase::rnd_next (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/storage/innobase/handler/ha_innodb.cc:10075
#7  0x0000000000f83725 in handler::ha_rnd_next (this=0x7ffe7c997610, buf=0x7ffe7c997b50 "\377")
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/handler.cc:3146
#8  0x00000000014e2b3d in rr_sequential (info=0x7ffe7cf47d60) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/records.cc:521
#9  0x0000000001584264 in join_init_read_record (tab=0x7ffe7cf47d10) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:2487
#10 0x0000000001581349 in sub_select (join=0x7ffe7cf47660, qep_tab=0x7ffe7cf47d10, end_of_records=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:1277
#11 0x0000000001580cce in do_select (join=0x7ffe7cf47660) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:950

棧幀5 String的等值比較

#0  Arg_comparator::compare_string (this=0x7ffe7c0072f0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_cmpfunc.cc:1669
#1  0x0000000000fde1e4 in Arg_comparator::compare (this=0x7ffe7c0072f0) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_cmpfunc.h:92
#2  0x0000000000fcb0a1 in Item_func_eq::val_int (this=0x7ffe7c007218) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/item_cmpfunc.cc:2507
#3  0x0000000001581af9 in evaluate_join_record (join=0x7ffe7c0077d8, qep_tab=0x7ffe7cb1dc70)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:1492
#4  0x000000000158145a in sub_select (join=0x7ffe7c0077d8, qep_tab=0x7ffe7cb1dc70, end_of_records=false)
    at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:1297
#5  0x0000000001580cce in do_select (join=0x7ffe7c0077d8) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:950
#6  0x000000000157eb8a in JOIN::exec (this=0x7ffe7c0077d8) at /root/mysqlall/percona-server-locks-detail-5.7.22/sql/sql_executor.cc:199

關(guān)于“MySQL中查詢字段數(shù)量多少會(huì)對(duì)查詢效率有影響”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。

網(wǎng)頁(yè)題目：MySQL中查詢字段數(shù)量多少會(huì)對(duì)查詢效率有影響
文章位置：http://muchs.cn/article38/pispsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、網(wǎng)站維護(hù)、服務(wù)器托管、品牌網(wǎng)站建設(shè)、網(wǎng)站營(yíng)銷、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)