現(xiàn)在存在一個(gè)案例：現(xiàn)有一個(gè)插入線程不斷的往數(shù)據(jù)庫(kù)里里面插入數(shù)據(jù)：[{"ts":1562902203,"event":"product1","direction":"buy","price":0.8},{"ts":1562902204,"event":"product1","direction":"sell","price":0.8}]現(xiàn)在存在N個(gè)查詢線程在做查詢操作，查詢內(nèi)容有：當(dāng)前時(shí)間減去X時(shí)間內(nèi)的最高價(jià)當(dāng)前時(shí)間減去X時(shí)間內(nèi)的最低價(jià)因?yàn)榇嬖趦蓚€(gè)因素：時(shí)間和價(jià)格，所以這兩個(gè)都得加索引。查詢頻率極高，假設(shè)X等于5分鐘，當(dāng)前是15:00:00，查詢最高價(jià)，查詢條件是14:55:00-15:00:00內(nèi)的最高價(jià)，假設(shè)是14:58:00是最高價(jià)。如果當(dāng)前是15:00:01其他不變，查詢條件是14:55:01-15:00:01內(nèi)的最高價(jià),結(jié)果很可能仍然是14:58:00是最高價(jià)。兩種情況的實(shí)際結(jié)果很大的情況下是一致的。所以出現(xiàn)了大量的查詢純粹是浪費(fèi)資源。但是15:00:01是最高價(jià)的情況也出現(xiàn)過多次，需求也對(duì)數(shù)據(jù)精準(zhǔn)有高要求?，F(xiàn)有的運(yùn)行方案是：mysql5.7ts和price都加索引。select*fromdatawhere`ts`>='14:55:00'orderbypricedesclimit1現(xiàn)在經(jīng)常會(huì)出現(xiàn)mysql的CPU壓力特別高，內(nèi)存壓力特別小?，F(xiàn)在希望得到一個(gè)方案，脫離數(shù)據(jù)庫(kù)來(lái)排序獲取，自己實(shí)現(xiàn)一個(gè)高效的方案，盡量把查詢壓力放到應(yīng)用服務(wù)器上來(lái)。補(bǔ)充一下，看到大家的答案都是在討論怎么緩存歷史最高價(jià)。重點(diǎn)是14:55:01-15:00:01的最高價(jià)與14:55:00-15:00:00不一定是重合的，只是可能重合。如果重合，那么是可以存下來(lái)last_max_price，用于減少篩選范圍。但是在查詢前是不知道是否重合的，而且這個(gè)歷史的last_max_price，只對(duì)重合有效，如果不重合是完全沒有意義的。這個(gè)需求的最大問題是區(qū)間每次都是變化的。下一次查詢的起點(diǎn)是14:55:01，上一次是14:55:00，起點(diǎn)不同結(jié)尾是15:00:01，上一次是15:00:00，也是不同的，如果上一次的最高價(jià)出現(xiàn)在14:55:00，那么現(xiàn)有答案的緩存方案都是無(wú)效的。