PS，所有的表都已经根据查询语句设置了索引，这个办法就不要想，还有什么别的办法
12 个解决方案
#1
你可以把数据量大的表分区，之后建分区索引，调节你的服务器的sga的值！分区是你不错的选择！
#2
提高显著吗，昨天我们优化一下业务流程，才提高了15分钟的效率，oracle不会这么差吧
#3
你描述的太简略了，也没有办法给你准确的提意见，但是，建议优化一下语句吧。
用sql_trace跟踪过吗？我想应该跟踪一下，搞清楚耗时到底在哪个具体步骤上，看执行计划有没有问题，特别大的那个表是否能避免全表扫描。
用sql_trace跟踪过吗？我想应该跟踪一下，搞清楚耗时到底在哪个具体步骤上，看执行计划有没有问题，特别大的那个表是否能避免全表扫描。
#4
索引能提高查询速度，但索引太多了会大大降低数据修改（insert update delete）速度
索引在检索的行数少于总行数的7%（已排序表）40%（未排序表）才提高速度
索引技术常见的有三种：B树索引、位图索引、索引组织表
70w的表根本不算大。sqlserver7都能管理900w记录在几毫秒内查出数据
我们的分区表单个分区都超过千万记录了。
索引在检索的行数少于总行数的7%（已排序表）40%（未排序表）才提高速度
索引技术常见的有三种：B树索引、位图索引、索引组织表
70w的表根本不算大。sqlserver7都能管理900w记录在几毫秒内查出数据
我们的分区表单个分区都超过千万记录了。
#5
要建立索引的，我们现在的项目中，几百万条数据，建了索引查询数度不到0.1S
#6
索引要设置对，你主要还是优化一下查询语句吧，在查询语句的条件中，能够筛选掉大部分数据的条件写在最后面，如果你先把70W条记录的表用一个条件大大变小范围以后，再和其它两张表关联，速度能快很多，另外加大ORACLE的高速缓冲区也有一定帮助，ORACLE有一个分析查询语句的工具，具体记不清了，你可以上网找一下，用来分析一下你的查询语句。
#7
这么点记录算不上大表. 把你的存储过程中SQL拿出来看一下执行计划, 看是否使用了该使用的索引, 表是否经过了分析等.
用好索引可以解决大部分的性能问题.
用好索引可以解决大部分的性能问题.
#8
索引经过trace肯定被使用了，最大的那个表之执行查询操作，所以加的索引应该不会造成性能下降，只会多占用磁盘空间，我们小组已经研究oracle优化两次了，几乎in全部换成了exist，也很少有null的条件可是好像还是很慢呀
#9
对了，那个70w记录的表确实是使用了全表扫描，可是怎么才能避免呢
#10
主要矛盾在于两个要进行两重循环的匹配，时间复杂度是m*n，而且在最大的表中会经常出现查找不到的情况（这是正常业务情况），有什么办法吗？
#11
你的sql有问题~
在改动数据结构来优化之前, 应该好好检查sql是不是最好的
在改动数据结构来优化之前, 应该好好检查sql是不是最好的
#12
可以试试临时表和数组
#1
你可以把数据量大的表分区，之后建分区索引，调节你的服务器的sga的值！分区是你不错的选择！
#2
提高显著吗，昨天我们优化一下业务流程，才提高了15分钟的效率，oracle不会这么差吧
#3
你描述的太简略了，也没有办法给你准确的提意见，但是，建议优化一下语句吧。
用sql_trace跟踪过吗？我想应该跟踪一下，搞清楚耗时到底在哪个具体步骤上，看执行计划有没有问题，特别大的那个表是否能避免全表扫描。
用sql_trace跟踪过吗？我想应该跟踪一下，搞清楚耗时到底在哪个具体步骤上，看执行计划有没有问题，特别大的那个表是否能避免全表扫描。
#4
索引能提高查询速度，但索引太多了会大大降低数据修改（insert update delete）速度
索引在检索的行数少于总行数的7%（已排序表）40%（未排序表）才提高速度
索引技术常见的有三种：B树索引、位图索引、索引组织表
70w的表根本不算大。sqlserver7都能管理900w记录在几毫秒内查出数据
我们的分区表单个分区都超过千万记录了。
索引在检索的行数少于总行数的7%（已排序表）40%（未排序表）才提高速度
索引技术常见的有三种：B树索引、位图索引、索引组织表
70w的表根本不算大。sqlserver7都能管理900w记录在几毫秒内查出数据
我们的分区表单个分区都超过千万记录了。
#5
要建立索引的，我们现在的项目中，几百万条数据，建了索引查询数度不到0.1S
#6
索引要设置对，你主要还是优化一下查询语句吧，在查询语句的条件中，能够筛选掉大部分数据的条件写在最后面，如果你先把70W条记录的表用一个条件大大变小范围以后，再和其它两张表关联，速度能快很多，另外加大ORACLE的高速缓冲区也有一定帮助，ORACLE有一个分析查询语句的工具，具体记不清了，你可以上网找一下，用来分析一下你的查询语句。
#7
这么点记录算不上大表. 把你的存储过程中SQL拿出来看一下执行计划, 看是否使用了该使用的索引, 表是否经过了分析等.
用好索引可以解决大部分的性能问题.
用好索引可以解决大部分的性能问题.
#8
索引经过trace肯定被使用了，最大的那个表之执行查询操作，所以加的索引应该不会造成性能下降，只会多占用磁盘空间，我们小组已经研究oracle优化两次了，几乎in全部换成了exist，也很少有null的条件可是好像还是很慢呀
#9
对了，那个70w记录的表确实是使用了全表扫描，可是怎么才能避免呢
#10
主要矛盾在于两个要进行两重循环的匹配，时间复杂度是m*n，而且在最大的表中会经常出现查找不到的情况（这是正常业务情况），有什么办法吗？
#11
你的sql有问题~
在改动数据结构来优化之前, 应该好好检查sql是不是最好的
在改动数据结构来优化之前, 应该好好检查sql是不是最好的
#12
可以试试临时表和数组