oracle数据库约200W数据查询非常慢，查询需要10几秒，经常查询超时，这个正常吗？有没有啥好的办法解决

Posted 2023-03-31

建立索引效果也不打，可能是什么问题？
数据库的索引 分区表都有

先确认一下问题，是代码操作的查询还是连接oracle工具操作的查询，优化大数据量主要先从三两方式入手，第一，建索引，这个有讲究：主要是针于你的查询条件(即是在where后面的字段建索引，有几个条件字段就建几个，如果有组合条件查询，那建联合索引)。第二点，就是按表中的数据，进行表分区，如按时间段进行分区，按区域进行分区，按单位或部门进行分区等。减少全表扫描。三，检查一下表空间大少。追问

代码操作的查询

追答

那这个还得根据代码的写法情况来处理，
那你可以分两部分来检查 ，代码的检查和数据库的检查，把
把代码每个消耗资源的代码执行时间打印出来，确定查询变慢的范围或原因
把可执行SQL放到连接数据库工具去执行，看执行时间有多长，如果是SQL原因，刚优化SQL,如果是数据库数据量的原因，则按前面回答的方式优化。
如果是代码原因：检查运行环境的内存，java虚拟机的内存这些是否有影响，设置二级缓存，在代码中检查，数据库连接方式，是否是IO读取消耗时间比较长，如果是，刚跟硬盘的转速和磁道有关，还要检查代码中业务处理的for是否存在或算法比较是否合理，并检查是否用到游标，确认游标和数据库连接都关闭了没有？，

参考技术A 如果是要把这些记录（200W）都取出来，这个时间应该是正常的，需要把这些记录全部从磁盘取出来显示。

如果是从200W里取一些数据出来，应该就不能花这么多时间。

为什么会有取200W条数据这样的需求？取出来做什么用？ 参考技术B 查询几条数据，查询的条件多吗，如果需要全表扫描的话，按指定的关键字进行分区，建立分区表，这样可以减少扫描，你可以试一下 参考技术C

使用 explain plan FOR，执行计划，看是否使用了索引进行查询

代码：通过查询执行计划，查看Oracle查询语句是否使用索引

参考技术D 1. 统计信息失真
2. 查询未使用到索引，即走的是全表扫描

看看查询计划吧

首次运行查询非常慢

【中文标题】首次运行查询非常慢

【英文标题】：First-run of queries are extremely slow

【发布时间】：2018-03-29 16:26:44

【问题描述】：

我们的 Redshift 查询在第一次执行时非常很慢。随后的执行速度要快得多（例如，45 秒 -> 2 秒）。在调查了这个问题之后，查询编译似乎是罪魁祸首。这是一个已知问题，甚至在 AWS Query Planning And Execution Workflow 和 Factors Affecting Query Performance 页面上也有提及。亚马逊本身对查询缓存的工作方式非常 tight lipped （tl;博士，这是一个你不应该担心的神奇黑匣子）。

我们尝试的其中一个方法是增加我们拥有的节点数量，但是我们并不期望它能够解决任何问题，因为无论如何查询编译都是单节点操作。它没有解决任何问题，但它是一个有趣的消遣。

如前所述，这是一个已知问题，但是，在任何在线讨论的地方，唯一的收获要么是“这只是你必须使用 Redshift 才能忍受的事情”或“这是一个超级笨拙的解决方法，它只适用于时间，因为我们不知道查询缓存是如何工作的”。

我们可以做些什么来加快编译过程或以其他方式处理这个问题？到目前为止，找到的最佳解决方案是“预先运行您可能希望在给定日期按计划运行的每个查询”，这不是很好，特别是考虑到我们对查询缓存的工作原理知之甚少.

【问题讨论】：

冷缓存问题并非 Redshift 独有。如果你想保持温暖，你需要一个脚本来偶尔戳一下它。

我们也面临着与迈克相同的问题。如果有人有任何替代解决方案或任何解决方案，请告诉我们。

@jai 物有所值 - 我们从未找到解决此问题的方法。企业认为这是一个交易破坏者，我们改用 Snowflake

【参考方案1】：

有 3 件事需要考虑

任何查询的第一次运行都会导致查询被“编译” 红移。这可能需要 2-20 秒，具体取决于它的大小。 相同查询的后续执行使用相同的编译代码， 即使 where 子句参数发生变化也不会重新编译。 运行查询时，数据测量为标记为“热” 反对它，并缓存在红移内存中。你不能（可靠地）手动 以任何方式清除它，除非重新启动集群。 Redshift 将“缓存结果”，具体取决于您的 Redshift 参数 （默认启用）redshift 将快速返回相同的结果 对于完全相同的查询，如果基础数据没有改变。如果 您的查询包括 current_timestamp 或类似的，那么这将 如果从缓存中停止。这可以通过SET enable_result_cache_for_session TO OFF; 关闭。

考虑到您的问题，您可能需要运行一些示例查询来预编译或重新设计您的查询（我猜您正在构建一些动态查询，这会极大地改变查询的形状）。 根据我的经验，更多的节点会增加编译时间。这个过程发生在主节点而不是数据节点上，并且通过考虑更多的数据节点而变得更加复杂。

【参考方案2】：

该查询实际上可能没有第二次运行 - 相反，Redshift 只是为同一查询返回相同的结果。

这可以通过关闭缓存来测试。运行这个命令：

SET enable_result_cache_for_session TO OFF;

然后，运行两次查询。每次执行都应该花费相同的时间。

结果缓存非常适合重复查询。与其对第一次执行“慢”感到失望，不如对后续缓存的查询“快”感到高兴！

【讨论】：

也许 - 但 2 秒对于缓存结果查询来说有点慢，你不觉得吗？除非那 2s 可能包括网络时间。通常这些是

@JonScott FWIW 我引用的“2 秒”不是经过严格测试的值。更多“几个数量级差异”的例子