我欲封天耳根小说,旷世神医

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

MySQL中COUNT查詢函數(shù)如何使用

MySQL中COUNT查詢函數(shù)如何使用，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)公司專注于企業(yè)網(wǎng)絡(luò)營銷推廣、網(wǎng)站重做改版、安多網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁面制作、商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為安多等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

首先創(chuàng)建一個表，只有id，name，sex三個字段，使用存儲過程隨機(jī)插入100萬條數(shù)據(jù)：

MySQL中COUNT查詢函數(shù)如何使用

首先，我們先貼下最基本的count函數(shù)語法：

select count(expr) from table;

可以看到count函數(shù)實(shí)際上需要傳入expr，這個expr一般取值有以下三個：

列名：會檢索對應(yīng)列值不為NULL的條數(shù)。
*：查詢符合條件的行數(shù)，和列值是否為NULL無關(guān)，返回結(jié)果都會返回。
常量：查詢符合條件的行數(shù)，和列值是否為NULL無關(guān)，返回結(jié)果都會返回。

count(*)，count(id)與count(1)效率對比

實(shí)際上對于count(*)和count(1)效率哪個更高，眾說紛壇。我們可以先看看效率對比：

MySQL中COUNT查詢函數(shù)如何使用

可以發(fā)現(xiàn)執(zhí)行速度兩條SQL語句是相差無幾的，count(1)和count(*)都是查詢?nèi)頂?shù)據(jù)行數(shù)，可能網(wǎng)上很多言論會說count(*)其實(shí)走的就是count(1)查詢，所以使用count(1)查詢可以節(jié)省轉(zhuǎn)換時間，實(shí)際上無論count(*)還是count(1)完全一致，都是表示指定非空表達(dá)式，所以會查詢所有符合條件的行數(shù)。為什么我會說這兩個語句執(zhí)行效果是一樣的？因?yàn)镸ysql官方文檔寫了這么一句話：

InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference.

所以說實(shí)際上count(*)與count(1)在執(zhí)行效率上是沒有區(qū)別的，那既然沒有區(qū)別我究竟要使用哪一個？我個人建議使用count(*)，因?yàn)镾QL92標(biāo)準(zhǔn)中制定count(*)為標(biāo)準(zhǔn)統(tǒng)計(jì)行數(shù)的語法，所以Mysql一直在不斷地對count(*)做一定的優(yōu)化。那有人說count(id)效率會不會更高？因?yàn)榭梢宰咧麈I索引，走索引查詢效率不是應(yīng)該更高？但是事實(shí)上count(id)查詢效率會比count(*)更慢。我們可以測試下：

MySQL中COUNT查詢函數(shù)如何使用

可能有人會納悶我們添加索引列目的不就是為了提高查詢效率？平時我們檢索數(shù)據(jù)屬于范圍查詢，查詢指定的數(shù)據(jù)，所以走索引可以提高查詢效率，但是count(id)選擇索引基數(shù)大的主鍵索引肯定效率更低。因?yàn)橹麈I索引和數(shù)據(jù)文件存放在一起，所以通過主鍵id取條數(shù)會檢索數(shù)據(jù)文件，count(id)會檢索整張表，然后遍歷取到每一行數(shù)據(jù)的id，然后返回server層對每一行的id，不為空count就 + 1，而count(*)一樣全表檢索，但是不會取id值，因?yàn)樵谒饕龢渚涂梢缘玫浇Y(jié)果，所以count(id)需要取到數(shù)據(jù)再過濾id為null的數(shù)據(jù)效率方面肯定是慢上不少的。

count(*)優(yōu)化

count(*)和count(1)沒什么差別，但是執(zhí)行時間都得1S多，而且數(shù)據(jù)量只是100萬條，所以我們肯定需要進(jìn)行適當(dāng)?shù)膬?yōu)化。因?yàn)閏ount(*)實(shí)際上查詢會使用最小字段的索引進(jìn)行優(yōu)化查詢，但是因?yàn)槟壳拔覀儽碇兄挥幸粋€主鍵索引，剛才也說過count(id)效率比count(*)低，所以默認(rèn)不使用索引查詢，我們可以使用explain測試下：

MySQL中COUNT查詢函數(shù)如何使用

可以看到查詢沒有走任何索引，所以效率很低是必然的。而count(*)剛才說過會默認(rèn)尋找最小字段的索引優(yōu)化查詢，所以我們給表增加一個status字段，弄成tinyint類型，并且添加二級索引，然后測試count(*)執(zhí)行時間:

MySQL中COUNT查詢函數(shù)如何使用

可以看到count(*)百萬級數(shù)據(jù)成功被優(yōu)化到0.32秒。完全符合我們的日常需求。所以說我們在需要取整表行數(shù)的時候就可以給表加一個非空的tinyint類型字段，并且添加二級索引，count(*)就會使用這個二級索引，優(yōu)化查詢速度。

count(col)

說完了count(*),我們知道了如果在需要返回全部行數(shù)時可以使用count(*),那接下來我們?nèi)绻枰樵冃彰粸榭盏目傂袛?shù)怎么做呢？我們可以加個where很快實(shí)現(xiàn)：

可以看到條數(shù)只有50萬條，因?yàn)榱硗?0萬條name值為null所以被忽略了，執(zhí)行時間1.38秒，這是我測試了多次取的最短時間。所以說百萬級數(shù)據(jù)就需要秒級明顯不符合需求，所以我們單字段篩選就可以使用count(字段名)，會自動將字段為空的行剔除掉，我們可以測試下：

可以看到1.1秒可以查詢到總條數(shù)，但是好像還是不滿足我們的需求，一樣還是秒級，我們使用explain查看下運(yùn)行參數(shù)：

可以看到因?yàn)闆]有使用到索引，所以導(dǎo)致全表檢索會掃描數(shù)據(jù)文件，現(xiàn)在我們對name字段添加一個索引，然后再測試：

可以看到只需要0.33秒就執(zhí)行完成，一樣使用explain查看下：

很顯然，本次查詢走索引了，加速查詢的原因是什么呢？因?yàn)槲覀冊趎ame字段創(chuàng)建了一個二級索引，在無二級索引時，count操作只能全表檢索數(shù)據(jù)。當(dāng)我們通過二級索引統(tǒng)計(jì)總條數(shù)，無需掃描數(shù)據(jù)文件，因?yàn)槎壦饕鎯Φ臄?shù)據(jù)就是name字段的值與主鍵id值。所以在count(col)時就可以在字段上添加一個二級索引加快檢索速率。

count函數(shù)指定where條件

這里一樣得分兩種情況：count(*)和count(col)。

count(*)：where條件添加索引，就可以使用索引優(yōu)化查詢。例如我們剛才添加的type列表示用戶賬號是否可用，我們現(xiàn)在需要查詢可用賬戶的總數(shù)量就可以這樣寫：

   
     
   
   
   select count(*) from order_info where type = 0;

可以explain查看下運(yùn)行參數(shù)可以發(fā)現(xiàn)確實(shí)使用到索引優(yōu)化查詢了：

count(col)：查詢列不為空的總條數(shù)并且添加where條件，就需要col添加索引并且where使用col進(jìn)行條件限制，我們可以先來看下name添加索引但是where使用sex限制條件的情況：

然后我們查詢name并且使用name限制條件看看是否可以使用索引優(yōu)化查詢：

可以看到查詢的列名和where條件的列明一致就可以走索引查詢提高效率了。所以說在數(shù)據(jù)量大的情況下要查詢總條數(shù)我們要合理去利用索引優(yōu)化查詢。

看完上述內(nèi)容，你們掌握MySQL中COUNT查詢函數(shù)如何使用的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

文章名稱：MySQL中COUNT查詢函數(shù)如何使用
文章路徑：http://fisionsoft.com.cn/article/gssppe.html

新聞中心

其他資訊