关于SELECT表的优化问题！

[zhjian6]

select ERP_MaterialType.MaterialTypeName,ERP_Material.MaterialName,ERP_Product.ProductName from ERP_Product,ERP_PM,ERP_Material,ERP_MaterialType where ERP_Product.ProductID="&id&" and ERP_PM.PID="&id&" and ERP_MaterialType.MaterialTypeID=ERP_PM.MTID and ERP_Material.MaterialID=ERP_PM.MID

"&id&" 为ID号的变量
如何写上面的SQL语句效率比较高？
有人建议我，多使用子查询会快点，因为现在数据量比较少，所以没办法比较
表：ERP_Product,,ERP_Material,ERP_MaterialType　以后是不会增加很多记录的
ERP_PM当日记型的表，以后数据会比较多
就怕数据一多，执行起来会非常慢，请问各位大侠，怎么写会比较好。
提高效率有什么原则，请多讲讲！

[paoluo]

可以利用别名将语句写的看起来简单些


select D.MaterialTypeName,C.MaterialName,A.ProductName
from ERP_Product A,ERP_PM B,ERP_Material C,ERP_MaterialType D
where A.ProductID="& id &" and B.PID="& id &"
and D.MaterialTypeID=B.MTID and C.MaterialID=B.MID

用子查询还没有用连接的效率高的。

另外，没有看到你的ERP_Product表与其余表是怎么关联的。

[zhjian6]

从原理来讲
比如：
a表有记录
1　2　3
4　5　6
7　8　9
b表有记录
10 11
12 13
连接查询是不是先把a , b表自然联接
1 2 3 10 11
1 2 3 12 13
4 5 6 10 11
4 5 6 12 13
7 8 9 10 11
7 8 9 12 13
再从中找个条件符合的
而子查询先从a表：
1　2　3
4　5　6
7　8　9
中找出条件符合的，再和b表进行联接，然后再找出条件符合的

是不是这样？
如果是这样，当a 表或者b表数据量比较多的时候，效率会成指数的降！

[zhjian6]

up

[paoluo]

从你给出的数据，A、B表没有任何关联条件的，那么数据量大了的话，效率肯定是有影响的。

[zhangchaoiii]

up

[zhjian6]

up

[jixiaojie]

up

[wangdehao]

先做投影，后做连接效率高，楼主原来的语句系统会自动优化的

[bugchen888]

select ERP_MaterialType.MaterialTypeName,ERP_Material.MaterialName,ERP_Product.ProductName from ERP_Product,ERP_PM,ERP_Material,ERP_MaterialType where ERP_Product.ProductID="&id&" and ERP_PM.PID="&id&" and ERP_MaterialType.MaterialTypeID=ERP_PM.MTID and ERP_Material.MaterialID=ERP_PM.MID


在ERP_PM的PID,MTID,MID上建索引；


还有虽然ERP_Product和ERP_PM没有做显式的连接,但实际上ERP_Product.ProductID="&id&" and ERP_PM.PID="&id&",就表明了这个栏位的等值连接,而且比直接写等值连接来的快...

[duanduan1122]

资料：
使用有效的查询设计


某些类型的查询天生就要占用大量的资源。这与大多数关系型数据库管理系统 (RDBMS) 常见的数据库和索引重大问题有关，而不是 SQL Server 特有的。它们并非是低效的，因为优化程序将以尽可能最为有效的方式来实现这些查询。但它们仍会占用大量的资源，而 SQL 面向集合的特性使它们显得效率很低。优化程序对于消除这些结构天生对资源的大量消耗毫无办法。与较简单的查询相比，它们非常耗费资源。尽管 SQL Server 将使用最为优化的访问计划，还是受可能占用大量资源的基线的限制。

例如：
• 大型结果集
• IN、NOT IN 及 OR 查询
• 高度非唯一 WHERE 子句
• !=（不等于）比较运算符
• 某些列函数，如 SUM
• WHERE 子句中的表达式或数据转换
• WHERE 子句中的局部变量
• GROUP BY 的复杂视图

[duanduan1122]

许多因素使得有必要使用这些查询结构。如果优化程序能在执行占用大量资源的部分查询之前限制结果集的大小，这些查询结构对性能的影响将被减少。下边给出了几个例子。

占用大量资源的查询：
SELECT SUM(SALARY) FROM TABLE

占用较少资源的查询：
SELECT SUM(SALARY) FROM TABLE WHERE
ZIP='98052'

占用大量资源的查询：
SELECT * FROM TABLE WHERE
LNAME=@VAR

占用较少资源的查询：
SELECT * FROM TABLE
WHERE LNAME=@VAR AND ZIP='98052'

在第一个例子中，SUM 操作无法通过索引加快。因为每一行都得读取并累加。假定在 ZIP 列上有一个索引，优化程序将很可能在应用 SUM 之前先用它来限制结果集。这样速度会快得多。

在第二个例子中，只有在运行时才会解析局部变量。但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，@VAR 值还是未知的，因而无法作为索引选择的输入项。

以上示例中用于改善性能的技术，涉及到用 AND 子句来限制结果集。作为另一种替代技术，可以使用一个存储过程，并把给 @VAR 的值作为参数传递给存储过程。

有些情况下，最佳做法是使用一组简单的查询，并通过临时表存储中间结果，这比使用单个复杂查询好得多。

对于大多数 RDBMS，大型结果集是很耗费资源的。您应该尽量避免把一个大型的结果集作为最终的数据选择返回给客户。限制结果集的大小，而让数据库系统完成本来属于它的一些功能，效率会更高。这将减少网络 I/O，并使得应用程序适合于通过慢速远程通讯链接的部署。随着应用程序扩展到更多的用户，它还会改善与并发相关的性能。

[duanduan1122]

应该对你有帮助的。