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