我正在对MAS90中使用的providex数据库运行查询。该查询有三个表连接在一起,速度一直很慢,但并非难以忍受,每次运行需要大约8分钟。该查询在where子句中有相当多的条件:Providex查询性能
我将忽略查询的选择部分,因为它的长和简单,只是三个表中的字段列表将用于结果。
但在8分钟的运行时间版本的表和其中子句是:(第一个参数是下界用户选择的日期范围的,第二个是上限)
FROM "AR_InvoiceHistoryDetail" "AR_InvoiceHistoryDetail",
"AR_InvoiceHistoryHeader" "AR_InvoiceHistoryHeader", "IM1_InventoryMasterfile"
"IM1_InventoryMasterfile"
WHERE "AR_InvoiceHistoryDetail"."InvoiceNo" = "AR_InvoiceHistoryHeader"."InvoiceNo"
AND "AR_InvoiceHistoryDetail"."ItemCode" = "IM1_InventoryMasterfile"."ItemNumber"
AND "AR_InvoiceHistoryHeader"."SalespersonNo" = 'SMC'
AND "AR_InvoiceHistoryHeader"."OrderDate" >= @p_dr
AND "AR_InvoiceHistoryHeader"."OrderDate" <= @p_d2
但是,事实证明,同一个表中的另一个日期字段需要与日期范围进行比较的日期字段。所以我将WHERE子句末尾的Order Dates更改为InvoiceDate。我还没有成功运行查询。我等了超过40分钟。我无法控制索引,因为这是一个MAS 90数据库,我不相信我可以直接更改数据库的特征。
什么可能导致如此大的(至少5倍)性能差异。是OrderDate可能已被索引,而InvoiceDate不是?我尝试了BETWEEN子句,但它似乎不能用于提供方言。我在自定义报表引擎中使用.NET通过ODBC接口。我一直在调试报告,并且当我在VS 8分钟报告等待的同一地点询问VS Break All时,它正在数据库执行点运行,所以它几乎肯定是我的查询或数据库中的某些内容这是搞砸了。
如果它仅仅是InvoiceDates未被索引的情况,那么我还可以在SQL的providex方言中做些什么来优化这些查询的性能?我应该改变我的标准顺序吗?本报告针对特定销售人员获得结果,这就是SMC条款存在的原因。先前的子句用于内部连接,最后一个子句用于日期范围。
我在OrderDate和InvoiceDate版本中都使用了相同的日期范围,并且已经将它们全部运行多次并获得了相同的结果。
祝你好运!也许我只是消息灵通,但我还没有听说过ProvideX。对于一个不太广泛采用的数据库这样一个具体问题,您最好找到供应商提供的论坛。也许我错了,有数百名SO用户可以提供帮助。我有点怀疑它。 – 2009-01-08 19:02:08
索引可能是这个问题,但只有当你有一个相当大的数据库或大规模动力不足的服务器。是否可以计算发票日期列而不是价值列?您可以查看服务器上的任务管理器/ Perfmon以查看它是否处于空闲状态,抖动磁盘或刻录CPU吗? – 2009-01-08 20:45:18