当前位置: 首页 > 面试题库 >

如何避免这个非常繁琐的查询使应用程序变慢?

姜阳
2023-03-14
问题内容

我们有一个在生产环境中运行的Web应用程序,有时客户抱怨该应用程序的运行速度很慢。

当我们检查应用程序和数据库的运行状况时,我们发现这个“宝贵的”查询同时由多个用户执行(因此给数据库服务器带来了极高的负载):

SELECT   NULL AS table_cat,
         o.owner AS table_schem,
         o.object_name AS table_name,
         o.object_type AS table_type,
         NULL AS remarks
FROM     all_objects o
WHERE    o.owner LIKE :1 ESCAPE :"SYS_B_0" AND
         o.object_name LIKE :2 ESCAPE :"SYS_B_1" AND
         o.object_type IN(:"SYS_B_2", :"SYS_B_3")
ORDER BY table_type, table_schem, table_name

我们的应用程序不执行此查询,我相信它是一个Hibernate内部查询。我几乎找不到关于为什么Hibernate进行此繁重查询的信息,因此非常感谢您对如何避免它的任何帮助!

生产环境信息:Red Hat Enterprise Linux 5.3(Tikanga),JDK 1.5,Web容器OC4J(whitin Oracle
Application Server),Oracle数据库10.1.0.4,用于JDK
1.2和1.3的JDBC驱动程序,Hibernate版本3.2.6.ga,连接池库C3P0版本0.9.1。

更新
:感谢@BalusC掌握了确实由Hibernate执行查询的功能,现在我对发生的事情有了更好的了解。我将解释我们处理hibernate会话的方式(是非常简单的,如果您对如何更好地处理它有任何建议,欢迎他们!)

我们有一个过滤器(实现javax.servlet.Filter),该过滤器在启动时(init方法)将构造会话工厂(可能仅发生一次)。然后,到达应用程序的每个HttpRequest都会通过过滤器并获得一个
新的 会话,并开始一个事务。流程结束后,它会通过过滤器返回,进行事务提交, 杀死
hibernate会话,然后继续前进页面(我们不会将hibernate会话存储在Http会话中,因为它在我们的测试)。

现在是我认为问题所在的部分。在我们的开发环境中,我们将应用程序部署在Tomcat 5.5中,并且当我们启动该服务时,所有过滤器都会立即启动,并且
启动 一次 。在OC4J的生产环境中,这种方式似乎不起作用。我们部署应用程序,只有在第一个请求到达时,OC4J才会实例化过滤器。

这使我认为OC4J实例化 每个
请求的筛选器(或至少多次,这仍然是错误的),从而在每个请求上创建会话工厂,并执行%&%#%$#查询,从而导致我的问题!

现在,对吗?我有办法配置OC4J使其仅实例化过滤器一次吗?

非常感谢大家抽出宝贵的时间对此做出回应!


问题答案:

好吧,经过几个月的研究,事实证明问题不是我的Web应用程序。问题是使用数据库的同一实例(不同用户)的其他Oracle Forms应用程序。

发生的事情是Oracle Forms应用程序正在锁定数据库上的记录,因此使数据库的几乎所有工作都非常缓慢(包括我钟爱的Hibernate查询)。

锁定的原因是没有对Oracle Forms应用程序的外键进行索引。因此,正如我的老板向我解释(他找到了原因),当用户在Oracle
Form应用程序中编辑主从关系的主记录时,如果没有其外键索引,则数据库 将锁定整个明细表 。这是因为Oracle
Forms的工作方式是更新主记录的所有字段,包括主键的字段,而外键则引用这些字段。

简而言之, 请不要让外键没有索引 。我们为此受了很多苦。

感谢所有花时间帮助您的人。



 类似资料:
  • 我有一个android应用程序,其中有一些文本视图需要实时更改。因此,请建议我如何经常更新文本视图。 这是我的密码:- 这是可行的,但一旦值在后端发生更改,它不会立即反映出来,直到再次调用resume函数。 请给我一个解决办法,这对我很重要。

  • 问题内容: 这个查询非常简单,我要做的就是按字段对给定类别中的所有文章进行排序: 但是它运行非常缓慢。这是EXPLAIN所说的: 有没有一种方法可以重写此查询或向我的PHP脚本中添加其他逻辑,以避免并加快速度? 表结构: 更新 我已经索引了。我想我的情况在文档中得到了解释: 在某些情况下,MySQL无法使用索引来解析ORDER BY,尽管它仍然使用索引来查找与WHERE子句匹配的行。这些情况包括:

  • 问题内容: 级联正是CSS变得特别而强大的原因。但在媒体查询的情况下,重叠 可 似乎有问题。 考虑以下CSS(CSS媒体查询重叠的连续规则): 因此,当屏幕正好为45em宽时,将根据标准CSS级联来处理45em处的重叠: 所有定义都将首先应用, 并将在此之后全部应用。 请考虑以下两个条件: 通常,所有文本都是,但是 查询A 是唯一的并且具有。 由于 查询B 适用于较大的视口,因此其文本具有CSS

  • 问题内容: 我有这个查询: 内部查询运行得非常快(不到0.1秒),以获取两个ID,一个ID表示状态1,一个ID表示状态2,然后它根据主键进行选择,以便对其进行索引。说明查询说,它仅使用where搜索135k行,我一生都无法弄清楚为什么这么慢。 问题答案:

  • 问题内容: 避免嵌套查询有多重要。 我一直学会避免像瘟疫一样躲避它们。但是对我来说,它们是最自然的事情。在设计查询时,我首先写的是嵌套查询。然后,我将其转换为联接,有时需要花费很多时间才能正确。而且很少会带来很大的性能提升(有时确实会提高) 他们真的那么糟糕吗?有没有一种方法可以使用没有临时表和文件排序的嵌套查询 问题答案: 这确实取决于我遇到的情况,我可以通过使用子查询来改进一些查询。 我知道的

  • 问题内容: 我有一个表,其中有一个索引(A列,B列)。我正在运行一个查询,如下所示: 这个查询很慢!该计划如下所示: Postgres似乎没有一次对5000个值进行一次索引扫描,而是一次对5000个值进行了一次索引扫描,这解释了为什么查询如此缓慢。 实际上,这样做是更快的方法: 获取结果,然后在应用程序内的B列上进行过滤(python)。 我真的更希望结果已经由Postgres在合理的运行时间下进