我遇到了DB性能瓶颈,现在在哪里？

Question

我现在有一些查询耗时太长(300毫秒),因为数据库已经增长到几百万条记录.幸运的是,对我来说,查询不需要查看大部分数据,最新的100,000条记录就足够了,所以我的计划是维护一个包含最新100,000条记录的单独表格并针对此运行查询.如果有人对更好的方法有任何建议,这将是伟大的.我真正的问题是,如果查询确实需要针对历史数据运行,有哪些选项,下一步是什么？我想到的事情:

• 升级硬件
• 使用内存数据库
• 在您自己的数据结构中手动缓存对象

这些事情是否正确,还有其他选择吗？某些数据库提供程序是否具有比其他数据库提供程序更多的功能来处理这些问题,例如将特定的表/索引指定为完全在内存中？

对不起,我应该提到这个,我正在使用mysql.

我忘了在上面提到索引.到目前为止,索引是我唯一的改进来源.为了识别瓶颈,我一直在使用maatkit进行查询,以显示是否正在使用索引.

我知道我现在正在远离问题的目的,所以也许我应该再做一个.我的问题是EXPLAIN说查询需要10毫秒而不是300毫秒jprofiler报告.如果有人有任何建议我会非常感激.查询是:

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)

Answer 1

考虑这样的设计变更不是一个好兆头 - 我敢打赌，您仍然有足够的性能可以使用 EXPLAIN 来挤出，调整数据库变量并改进索引和查询。但你可能已经过了“尝试一些东西”效果很好的阶段。这是一个学习如何解释分析和日志，并利用所学知识对索引和查询进行特定改进的机会。

如果您的建议不错，您应该已经可以告诉我们原因了。请注意，这是一种流行的悲观主义——

你见过的最可笑的悲观主义是什么？