摘要：
一個(gè)接口從開始開發(fā)到測(cè)試再到上線，相應(yīng)速度都很快，但是過了兩三個(gè)月，發(fā)現(xiàn)這個(gè)接口響應(yīng)速度捉急啊，達(dá)到了4.5s左右，給用戶的感覺像是出bug了，就會(huì)使勁兒點(diǎn)擊，結(jié)果導(dǎo)致了點(diǎn)擊量是PV的4倍，真是個(gè)不好的體驗(yàn)啊（題外話），著手排查問題。
過程
第一步當(dāng)然是查詢log日志了，找到對(duì)應(yīng)的接口，看到執(zhí)行的幾條sql語句都挺正常的，因?yàn)楫?dāng)時(shí)測(cè)試已經(jīng)通過，于是通過測(cè)量整個(gè)接口函數(shù)執(zhí)行時(shí)間，發(fā)現(xiàn)這個(gè)函數(shù)確實(shí)從開始到結(jié)束總共執(zhí)行了4.5秒左右，然后返回去看日志中的幾條sql語句，分別到數(shù)據(jù)庫中執(zhí)行，發(fā)現(xiàn)其中起一條查詢語句執(zhí)行的時(shí)間是4.2s左右，總共時(shí)間4.5s，這一條語句就是4.2s，問題就在這里，再回到代碼中，找到執(zhí)行該語句的函數(shù)，原來是sequelize框model提供的方法findAndCountAll（顧名思義查詢所有用戶并且統(tǒng)計(jì)總數(shù)），當(dāng)數(shù)據(jù)庫中存儲(chǔ)的量小時(shí)，不會(huì)有啥問題，但是當(dāng)數(shù)據(jù)量龐大，這時(shí)再去遍歷所有數(shù)據(jù)就會(huì)花費(fèi)許多時(shí)間，隨著數(shù)量增大，時(shí)間也會(huì)增長。
解決方法
要么直接執(zhí)行統(tǒng)計(jì)總數(shù)的sql語句（比如：select count(*) from user where sp='test'），要么將findAndCountAll替換成count，即可解決問題，重新構(gòu)建項(xiàng)目，訪問該接口，響應(yīng)時(shí)間明顯短了數(shù)倍。
