問(wèn)題描述

描述問(wèn)題：目前想用SQL語(yǔ)句來(lái)查詢(xún)一個(gè)表（50萬(wàn)條），并將表內(nèi)昵稱(chēng)為空的用戶(hù)Openid拿出來(lái)，每百條查詢(xún)一次。環(huán)境MySQL。

問(wèn)題關(guān)鍵：一次性取出，分百條查詢(xún)，也會(huì)給服務(wù)器造成很大壓力（*1），能不能讓SQL查詢(xún)出100條符合結(jié)果的記錄，并返回最后一條的ID？

拓展：除了我這種想法，業(yè)界有沒(méi)有一個(gè)合適的方案？或者關(guān)于SQL大容量查詢(xún) 的一些書(shū)籍。

*1：首先，我的服務(wù)器是小水管，50萬(wàn)條已經(jīng)相當(dāng)重了。其次，就算我現(xiàn)在擴(kuò)展服務(wù)器配置，假設(shè)某天達(dá)到了1億條，也會(huì)成為很大的負(fù)載壓力。

表結(jié)構(gòu)：id openid nickname avatar

部分openid的nickname或avatar(頭像)是空的，想要每次查出100個(gè)nickname或avatar(頭像)為空的openid，并調(diào)用微信接口，將獲取到的信息插入。

問(wèn)題解答

能不能讓SQL查詢(xún)出100條符合結(jié)果的記錄，并返回最后一條的ID？

這個(gè)問(wèn)題有點(diǎn)奇怪，到底是要返回100條數(shù)據(jù)呢？還是返回這100條數(shù)據(jù)里的最后一條ID呢？

首先50W條數(shù)據(jù)不算多，除非部署服務(wù)器的機(jī)器性能非常差，所以查詢(xún)速度應(yīng)該不至于很慢（除非你寫(xiě)了很復(fù)雜或者性能很低的SQL），分多次取出的話的確可以減輕數(shù)據(jù)庫(kù)壓力，但會(huì)增加網(wǎng)絡(luò)傳輸壓力。

另外，50W表數(shù)據(jù)的解決方案跟1E表數(shù)據(jù)的解決方案是完全不同的，所以不要妄想一套方案可以一勞永逸。

附上SQL：

SELECT DISTINCT openid FROM tableWHERE nickname IS NULLOR avatar IS NULLORDER BY id DESCLIMIT 100

由于用到了OR，所以估計(jì)用不上nickname和avatar的索引，或者你可以增加一個(gè)叫completed的字段，表示該條記錄是否已經(jīng)完善（即nickname和avatar均不為空，在程序插入數(shù)據(jù)時(shí)就維護(hù)該字段），這樣你的查詢(xún)SQL就可以避免OR連接了。

把需要查詢(xún)的字段都建上索引，在你現(xiàn)在這個(gè)場(chǎng)景下千萬(wàn)級(jí)數(shù)據(jù)都不會(huì)有壓力

1.索引加了沒(méi)有？2.SQL優(yōu)化一下

50萬(wàn)數(shù)據(jù)真心不算多啊。

搞不懂你要實(shí)現(xiàn)什么功能，查出100條卻只返回最后一條的一個(gè)列，沒(méi)意義，區(qū)區(qū)50w數(shù)據(jù)而已，非要實(shí)現(xiàn)加索引寫(xiě)存儲(chǔ)過(guò)程也就差不多了480w行的表查符合條件的列并返回所有整行，10秒而已，你的問(wèn)題可能出在符合條件的行太多輸出時(shí)內(nèi)存不夠，你可以寫(xiě)游標(biāo)把結(jié)果一條一條插入一張新表，時(shí)間慢點(diǎn)而已。

加索引，或者把數(shù)據(jù)庫(kù)定時(shí)寫(xiě)入緩存

你這樣很沒(méi)意思，搞得我聲望成負(fù)的了，結(jié)果不理想可以討論，直接刪算什么