COUNT(*)
查询也需要数分钟才能执行。最后我把它们分成几个表来进行分区。我的问题是,有没有一些模式或设计技术可以处理这种问题(大量记录)?在处理大量记录方面,MSSQL或Oracle哪个更好?备注: 上述的
COUNT(*)
问题只是一个例子,在实际应用中,这个应用程序进行crud功能和一些聚合查询(用于报告),但并没有什么复杂的内容。只是由于数据量大,执行某些查询需要相当长的时间(数分钟)。COUNT(*)
查询也需要数分钟才能执行。最后我把它们分成几个表来进行分区。我的问题是,有没有一些模式或设计技术可以处理这种问题(大量记录)?在处理大量记录方面,MSSQL或Oracle哪个更好?COUNT(*)
问题只是一个例子,在实际应用中,这个应用程序进行crud功能和一些聚合查询(用于报告),但并没有什么复杂的内容。只是由于数据量大,执行某些查询需要相当长的时间(数分钟)。在整个表上使用 count(*) 实际上是经常要做的事情吗?
InnoDB 必须执行完整的表扫描以计算行数,如果你确实想要计算所有行,则这显然会影响性能,但这并不意味着表上的其他操作将变慢。
通过正确的索引,MySQL 在检索比表格更大的数据时非常快。索引的问题在于它们可能会损害插入速度,特别是对于大型表格,因为一旦索引所需空间达到某个阈值(可能是内存中保留的大小),插入性能就会急剧下降。但如果你只需要适度的插入速度,MySQL 应该可以满足你的所有需求。
任何其他数据库都会在检索速度和插入速度之间进行类似的权衡;它们可能更适合你的应用程序,也可能不是。但我会首先看看如何正确使用索引并可能重写你的查询,然后再尝试其他数据库。就我们选择 MySQL 最初是因为我们发现它的性能最好。
请注意,MySQL 中的 MyISAM 表格存储总表大小。他们保持这样做是因为在某些情况下对优化器有用,但一个副作用是整个表上的 count(*) 确实非常快。这并不一定意味着它们在任何其他方面都比 InnoDB 更快。
我在这个Stackoverflow帖子中详细回答了一个类似的问题,描述了两个系统架构的优点。从数据仓库的角度来看,这样做在一定程度上是正确的,但许多差异也对事务性系统很重要。
然而,2500万行并不是一个超大型数据库(VLDB),如果您遇到性能问题,应该考虑索引和调整。您不需要使用Oracle来支持2500万行的数据库 - 您还需要增加3个数量级才能真正进入VLDB领域。
您要求的是一本书般的答案,因此我建议您获取有关数据库的好书。有很多种选择。
以下是一些数据库基础知识:
首先,您需要一个出色的数据模型,该模型不仅基于您需要存储的数据,而且还基于使用模式。 良好的数据库性能始于良好的架构设计。
其次,根据预期的查找和更新需求在列上放置索引,因为更新性能经常被忽视。
第三,如果有可能,请勿在where子句中放置函数。
第四,使用质量设计的-咳咳-RDBMS引擎。我恭敬地表示,尽管它在最近的过去取得了很大进展,但mysql并不符合条件(对那些希望争论它终于在最近时代达到标准的人表示歉意)。现在不再需要在高价格和质量之间做出选择;Postgres(又称PostgreSql)是开源的,并且真正出色-并且具有满足您需求的所有插件。
最后,了解您要求数据库引擎执行的操作-获得某些内部见解-以便更好地判断哪些操作是昂贵的以及原因。
我要赞同@Mark Baker的观点,你需要在表上建立索引。
对于除了你选择的查询之外的其他查询,你还应该知道,在查询中使用IN()这样的结构比一系列OR语句更快。有很多小步骤可以加速单个查询。
索引是处理大量记录的关键,但查询语句的编写方式也会产生很大的影响。具体的性能调优方法因数据库而异,但通常应避免返回比实际需要更多的记录或字段,确保所有连接字段都被索引(以及常见的where子句字段),避免使用游标(尽管我认为这在Oracle中不如SQL Server那么重要,但我不知道mySQL如何)。
硬件也可能成为瓶颈,特别是如果您在同一台机器上运行除数据库服务器之外的其他东西。
性能调优是一个非常技术性的主题,无法在这样的格式中得到很好的回答。我建议您获取一本性能调优书籍并阅读它。这里有一个针对mySQL的链接: http://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716