我已經遇到了數據庫性能瓶頸，現在呢？

我有一些查詢花費的時間太長（300ms），現在數據庫已經增長到幾百萬條記錄。幸運的是，查詢不需要查看大部分數據，最新的100,000條記錄就足夠了，因此我的計劃是維護一個包含最近100,000條記錄的單獨表格，並針對此進行查詢。如果任何人有任何建議，以更好的方式做到這一點很好。我真正的問題是，如果查詢確實需要針對歷史數據運行，那麼有什麼選擇？下一步是什麼？我想過的東西：我已經遇到了數據庫性能瓶頸，現在呢？

升級硬件
內存數據庫手動
緩存中的對象在自己的數據結構使用的

這些東西是正確的，是否有任何其他選擇？一些DB提供者是否比其他人有更多的功能來處理這些問題，例如指定一個特定的表/索引完全在內存中？

對不起，我應該提到這一點，我正在使用mysql。

我忘了在上面提到索引。到目前爲止，索引一直是我唯一的改進來源，相當誠實。爲了找出瓶頸，我一直在使用maatkit查詢來顯示索引是否被利用。

我知道我現在已經遠離了問題的目的，所以也許我應該再做一個。我的問題是EXPLAIN說這個查詢需要10ms而不是jmsofiler報告的300ms。如果有人有任何建議，我會很感激。查詢是：

select bv.* 
from BerthVisit bv 
inner join BerthVisitChainLinks on bv.berthVisitID = BerthVisitChainLinks.berthVisitID 
inner join BerthVisitChain on BerthVisitChainLinks.berthVisitChainID = BerthVisitChain.berthVisitChainID 
inner join BerthJourneyChains on BerthVisitChain.berthVisitChainID = BerthJourneyChains.berthVisitChainID 
inner join BerthJourney on BerthJourneyChains.berthJourneyID = BerthJourney.berthJourneyID 
inner join TDObjectBerthJourneyMap on BerthJourney.berthJourneyID = TDObjectBerthJourneyMap.berthJourneyID 
inner join TDObject on TDObjectBerthJourneyMap.tdObjectID = TDObject.tdObjectID 
where 
BerthJourney.journeyType='A' and 
bv.berthID=251860 and 
TDObject.headcode='2L32' and 
bv.depTime is null and 
bv.arrTime > '2011-07-28 16:00:00'

，並從EXPLAIN輸出：

+----+-------------+-------------------------+-------------+---------------------------------------------+-------------------------+---------+------------------------------------------------+------+-------------------------------------------------------+ 
| id | select_type | table     | type  | possible_keys        | key      | key_len | ref           | rows | Extra             | 
+----+-------------+-------------------------+-------------+---------------------------------------------+-------------------------+---------+------------------------------------------------+------+-------------------------------------------------------+ 
| 1 | SIMPLE  | bv      | index_merge | PRIMARY,idx_berthID,idx_arrTime,idx_depTime | idx_berthID,idx_depTime | 9,9  | NULL           | 117 | Using intersect(idx_berthID,idx_depTime); Using where | 
| 1 | SIMPLE  | BerthVisitChainLinks | ref   | idx_berthVisitChainID,idx_berthVisitID  | idx_berthVisitID  | 8  | Network.bv.berthVisitID      | 1 | Using where           | 
| 1 | SIMPLE  | BerthVisitChain   | eq_ref  | PRIMARY          | PRIMARY     | 8  | Network.BerthVisitChainLinks.berthVisitChainID | 1 | Using where; Using index        | 
| 1 | SIMPLE  | BerthJourneyChains  | ref   | idx_berthJourneyID,idx_berthVisitChainID | idx_berthVisitChainID | 8  | Network.BerthVisitChain.berthVisitChainID  | 1 | Using where           | 
| 1 | SIMPLE  | BerthJourney   | eq_ref  | PRIMARY,idx_journeyType      | PRIMARY     | 8  | Network.BerthJourneyChains.berthJourneyID  | 1 | Using where           | 
| 1 | SIMPLE  | TDObjectBerthJourneyMap | ref   | idx_tdObjectID,idx_berthJourneyID   | idx_berthJourneyID  | 8  | Network.BerthJourney.berthJourneyID   | 1 | Using where           | 
| 1 | SIMPLE  | TDObject    | eq_ref  | PRIMARY,idx_headcode      | PRIMARY     | 8  | Network.TDObjectBerthJourneyMap.tdObjectID  | 1 | Using where           | 
+----+-------------+-------------------------+-------------+---------------------------------------------+-------------------------+---------+------------------------------------------------+------+--------------------------------------- 

7 rows in set (0.01 sec)

來源

2011-07-28 James

您正在使用哪種RDBMS？ –

EXPLAIN PLAN在哪裏說瓶頸是你的麻煩問題？ –

「所以我的計劃是用最近的100,000條記錄維護一個單獨的表並且針對這個查詢運行查詢」 - 聽起來像個壞主意。 –