人生路漫,与你相伴...

在SQL 2005 上用Oralce 9i建立连接服务器没有问题， 当改用Oralce 10g的客户端建立连接服务器时出现如上的错误. 经过查询相关资料，发现需要在 连接服务器>>提供者>>OraOledb.Oralce 上面属性必须设定允许inprocess

1. 数据库访问性能优化　
　
数据库的连接和关闭

访问数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数据库交换信息以通过身份验证，比较耗费服务器资源。ASP.NET中提供了连接池(Connection Pool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。连接池的大小是有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭，从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。 　　

使用存储过程 　
　
存储过程是存储在服务器上的一组预编译的SQL语句，类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能，信息处理极为迅速。使用存储过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。另外，存储过程在服务器端运行，独立于ASP.NET程序，便于修改，最重要的是它可以减少数据库操作语句在网络中的传输。

优化查询语句
　　
ASP.NET中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句中包含子查询语句，充分利用索引等。 　　

2. 字符串操作性能优化　
　
使用值类型的ToString方法
　　
在连接字符串时，经常使用"+"号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装箱操作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值复制到新创建的对象中。使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。 　　

运用StringBuilder类 　　

String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象，其方法ToString 对性能的提高并非很显著。在处理字符串时，最好使用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert等方法直接对字符串进行操作，通过 ToString方法返回操作结果。 　　其定义及操作语句如下所示：


int num; 　　System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 　　str.Append(num.ToString()); //添加数值num 　　Response.Write(str.ToString); //显示操作结果3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要

默认情况下，ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。

仅对需要的应用程序启用身份验证。

默认情况下，身份验证模式为 Windows，或集成 NTLM。大多数情况下，对于需要身份验证的应用程序，最好在 Machine.config 文件中禁用身份验证，并在 Web.config 文件中启用身份验证。根据适当的请求和响应编码设置来配置应用程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。
　　
考虑对应用程序禁用 AutoEventWireup。

在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩(例如 Page_Load)。如果页面开发人员要使用这些事件，需要在基类中重写这些方法(例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。

从请求处理管线中移除不用的模块。

默认情况下，服务器计算机的 Machine.config 文件中节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需要自定义它。例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从列表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进入和离开代码。

4. 一定要禁用调试模式　　

在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。 　　

5. 对于广泛依赖外部资源的应用程序，请考虑在多处理器计算机上启用网络园艺　　

ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程(每个CPU一个)，并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象(这里只是提及两种可能性)，则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。　　

6. 只要可能，就缓存数据和页输出　　

ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求(特别是在站点中预期将有较大通讯量的区域)，可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。


7. 选择适合页面或应用程序的数据查看机制　　

根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。 　　

8. 将 SqlDataReader 类用于快速只进数据游标　　

SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息，请参见通过 ASP.NET 访问数据。 　　

9. 将 SQL Server 存储过程用于数据访问　　

在 .NET Framework 提供的所有数据访问方法中，基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。 　　

10. 避免单线程单元 (STA) COM 组件　　

默认情况下，ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。


Dim myComp as new MySTAComponent() Public Sub Page_Load() myComp.Name = "Bob" End Sub


首选机制是推迟对象的创建，直到以后在 STA 线程下执行上述代码，如下面的例子所示。


Dim myComp Public Sub Page_Load() myComp = new MySTAComponent() myComp.Name = "Bob" End Sub

推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。 　　

11. 将调用密集型的 COM 组件迁移到托管代码　　

.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。 　　

12. 在 Visual Basic .NET 或 JScript. 代码中使用早期绑定　　

以往，开发人员喜欢使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

JScript. .NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：被显式声明为 Object，是无类型声明的类的字段，是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。 　　最后一个差别比较复杂，因为如果 JScript. .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。

var A; 　　var B; 　　A = "Hello"; 　　B = "World"; 　　B = 0; 为了获得最佳的性能，当声明 JScript. .NET 变量时，请为其分配一个类型。例如，var A : String。

13. 使请求管线内的所有模块尽可能高效　　

请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。


14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向　　

采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
　　
15. 必要时调整应用程序每个辅助进程的线程数　　

ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。

注意：辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。 　　

16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理　　

小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。 　　

17. 如果有大型 Web 应用程序，可考虑执行预批编译　　

每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次访问您的站点时，页面及其程序集将已被编译。没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。还应尽量避免更改应用程序的 \bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 \bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。

18. 不要依赖代码中的异常　　

因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。


　try 　　{ 　　result = 100 / num; 　　} 　　catch (Exception e) 　　{ 　　result = 0; 　　} 　　// ...to this. 　　if (num != 0) 　　result = 100 / num; 　　else 　　result = 0;

19. 使用 HttpResponse.Write 方法进行字符串串联

该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。


Response.Write("a"); 　　Response.Write(myString); 　　Response.Write("b"); 　　Response.Write(myObj.ToString()); 　　Response.Write("c"); 　　Response.Write(myString2); 　　Response.Write("d"); 20. 除非有特殊的原因要关闭缓冲，否则使其保持打开

禁用 Web 窗体页的缓冲会导致大量的性能开销。 　　

21. 只在必要时保存服务器控件视图状态　　

自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值(您不需要编写任何代码)。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。


您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用：


注意:@ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量，请(通过将 trace="true" 属性包括在 @ Page 指令中)启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。

22. 避免到服务器的不必要的往返过程　　

虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript. 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。

使用 Page.IsPostBack 避免对往返过程执行不必要的处理

如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的。

使用 Page.IsPostBack 属性有条件地执行代码

例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。


void Page_Load(Object sender, EventArgs e) 　　{ 　　// Set up a connection and command here. 　　if (!Page.IsPostBack) 　　{ 　　String query = "select * from Authors where FirstName like '%JUSTIN%'"; 　　myCommand.Fill(ds, "Authors"); 　　myDataGrid.DataBind(); 　　} 　　}

由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。 　　

23. 当不使用会话状态时禁用它　　

并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。 　　若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如:


注意:如果页需要访问会话变量，但不打算创建或修改它们，则将@ Page 指令中的 EnableSessionState 属性设置为ReadOnly。还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如:


24. 仔细选择会话状态提供程序　　

ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。 　　

25. 不使用不必要的Server Control

ASP.net中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control。 　　

26. ASP.NET应用程序性能测试　　

在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application Strees Tool (WAS)是Microsoft发布的一个免费测试工具，可以从http://webtool.rte.microsoft.com/上下载。它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均TTLB等性能汇总报告。 Application Center Test (ACT) 是一个测试工具，附带于Visual Studio.NET的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户机同时测试的能力。服务器操作系统"管理工具"中的"性能"计数器，可以对服务器进行监测以了解应用程序性能。 　　

结论：

对于网站开发人员来说，在编写ASP.NET应用程序时注意性能问题，养成良好的习惯，提高应用程序性能，至少可以推迟必需的硬件升级，降低网站的成本。

(8)SELECT  (9)DISTINCT  (11)TOP <select_list>

(1)FROM <left_table>

(3)<join_type>JOIN <right_table>

(2)ON <join_condition>

(4)WHERE <where_condition>

(5)GROUP BY <group_by_list>

(6)WITH {CUBE | ROLLUP}

(7)HAVING <having_condition>

(10)ORDER BY <order_by_list>

  

1. 執行迪卡爾乘積 (交叉關聯)
2. 應用ON篩選器(聯結條件)
   1. 在SQL中邏輯表達式的可能值包括 True, False, Unknown 三種, 稱為 三值邏輯

3. 添加外部行(Outer Row)
   1. 左外部關聯(left outer join)把左表標記為保留表
   2. 右外部關聯(right outer join)把右表標記為保留表
   3. 完全外部關聯(full outer join)把兩個表都標記為保留表

4. 應用Where 篩選器
5. 分組(GROUP BY)
6. 應用CUBE 或 ROLLUP選項
7. 應用HAVING篩選器
8. 處理SELECT列表
9. 應用DISTINCT子句
10. 應用ORDER BY子句
11. 應用TOP選項

贏 20%做老大

這是兩年前在網路上流傳的一則故事：有一位工程師在一家公司工作三十年，退休了。他對該公司的機器及產品瞭如指掌。幾年後，該公司的一套機器故障，全公司的人都沒法找出問題來。絕望中，他們只好把退休的工程師找回來。這位工程師看了一個小時後，從上衣口袋拿出一枝粉筆，用粉筆在一個零件上畫了一個大叉叉指出：「這就是你們的問題。」 知識與常識 杜書伍：懂八十%叫常識，真正的專業在二十%，那才是知識 公司把零件換了，機器操作正常。但是不久，公司收到一張十萬元的帳單，是這位退休工程師的收費。公司老闆火大了，認為一個小時不值這麼多錢，就要求送一張明細表。這位工程師的回函是：「粉筆，一元；知道在哪裡畫叉叉，九萬九千九百九十九元。」 就在工程師畫下叉叉的同時，他腦中三十年的工作經驗正以電影濃縮快轉速度進行，頃刻間他閃過四個與該問題相連的可能解決方案、綜合了同樣問題場景卻失敗二十七次的經驗值、和一百五十三次獨自思索突破工作瓶頸的深層反省。 決定工程師拿到九萬九千九百九十九元的那一筆，究竟是什麼？聯強國際總裁兼執行長杜書伍說，在一個行業裡，你懂八十%叫做「常識」，而不是「知識」，因為大家都懂八十％。而且，可能只要花二十％的時間就能學會這八十％。其實，真正的專業再最後的二十％，那才是真正的「知識」。他談到多年的用人經驗，剛入行的年輕人，很可能前兩年所學到的都只是該行業的常識：「他學習一下，就說『喔，我學會了！』實際上他學的非常淺薄。只是像煙火一樣，『砰』的一聲好像看起來不錯，但事實上不會產生效益！」 「光靠常識的人，猶如只會一招半式。」杜書伍接著說，應付一般性的運作尚可，有時也可運作得很熟練，但針對每一次應用可能遇到的細節不同，不見得能精準拿捏每一環節該使幾分力、該如何變通，使得執行起來有隔靴搔癢之感，好像做了，卻又覺得少了什麼。 當一個人擁有「決勝二十％」的知識與能力後，手上握有的粉筆，就不只值一元，而能附加出九萬九千九百九十九的價值。不過，從「常識階級」進入「知識階級」，必須經歷一段漫長的浸泡於思考。然後，腦袋會產生許多促使事件成功的直覺。 二十八分鐘練習 大前研一在電車上思考問題解決方案，三年成為全球客戶最多的管理顧問 日本管理大師大前研一是個絕佳的例子。他本來是一位從事核子反應爐設計工作九年的工程師，當他進入剛成立的麥肯錫東京事務所，若沒有將企管用語轉換為熟知的核子學用語，腦子就無法思考；而連「break-even analysis」是損益平衡分析都不懂的他，還被頂頭上司罵出「你真的是公牛乳頭」的話(編按：公牛的乳頭無法哺乳，意指一無是處)。於是，在找尋學習材料的過程，他發現公司圖書室有一大批麥肯錫客戶資料的個案微卷，白天他負責翻譯、答覆海外有關日本的市場調查，晚上就投入研究微卷，每天夜裡搭十點四十八分的電車回家，假日也不間斷。 此外，他也嘗試在短時間進行問題分析與提出對策大綱。好比說，把搭車看到第一眼的廣告作為當天練習題目，利用二十八分鐘的車程，思考問題解決方案。像是看到一則蕃茄醬廣告，大前研一將問題設定為「如何擴大某一產品的蕃茄醬市場」在抵達公司前，他就思考「這樣的廣告看板是否能增加銷路」以及「蕃茄醬與蕃茄汁的不同」等問題。久了，一天就不再限於一個題目。經過長達一年的電車訓練，只要他的客戶一提出問題與要求，大前研一都能立即在腦中行程解決圖案。 一年後，他整理筆記並出版《企業參謀》一書，接下來的一年，大前研一至少演講數百場，使得原本幾乎無案可做的日本麥肯錫業務量驟增，他自己也在進入公司第三年成為全球擁有最多客戶、最忙碌的管理顧問，甫三十歲的他與「新力」的盛田昭夫、「富士」的小林陽太郎」等多位日本重量級企業經營者，在國際會議上一起列席，介紹日式企業經營模式，顧問費高達每日一百五十萬日圓(約合新台幣四十三萬元)。 關鍵行銷策略 行銷顧問建議說出釀製啤酒的故事，六個月讓施麗茲由第八變第一 另一個例子出自《選對池塘釣大魚》一書，內容提到，施麗茲啤酒(Schlitz beer)　在一九二Ｏ年早起，約有十家不同啤酒在市場上競爭，當時施例子啤酒排名第八。後來，因為一位行銷顧問，讓施麗茲的排名躍升到第一。 當時，這名顧問為了弄懂這個領域的專業知識以及製酒過程，特別到釀場跑了一趟。施麗茲啤酒工廠設在密西根湖畔，當時的湖水非常清澈，即使如此，他們仍鑽了兩口五百呎深的自流井，因為他們必須鑽到夠深，才能找到正確的水質，並且把其中酒的礦物質調到完美的地步。工廠人員解釋他們在五年內進行了一千六百二十三次的實驗，以開發出最好的酵母，並展示如何在進行釀製前三次蒸餾水的程序。在裝酒時，每個瓶子都用攝氏六百度的蒸氣消毒過，以確保殺死所有細菌。 這位顧問建議公司管理層把這不尋常的釀製過程告訴消費者，管理層說：「為什麼要這麼做？所有的啤酒商都是做一樣的事！」行銷顧問指出，所有的啤酒商在廣告上都傳送同樣的訊息：「我們的啤酒最純。」但他們都沒有對飲者解釋「純」是什麼意思，只是「純、純、純」說個不停。這件事情的關鍵在於：誰能成為第一個說出故事，並且解釋原因及過程的人，誰就會在市場上得到領先地位。 這位行銷顧問擬定的新行銷策略，在六個月後，讓施麗茲啤酒在啤酒市場一躍為龍頭。 專注一道菜 楊媽媽研究發燕窩二十幾年，連日本大飯店都請她赴日指導 施麗茲行銷顧問、大前研一的腦袋都蘊藏了決勝二十的知識，這樣的知識或能力只存在白領的腦袋裡嗎？馥園的楊媽媽與斐瑟髮廊的髮型師林錦惠顯然不屬於前述的歸類，然而，她們也擁有影響事情成敗的關鍵能力。 坐落在臨沂街，一棟古色古香的仿古建築裡，經營了二十四年的高價餐廳馥園是政商界公認最私密豪華的高級餐廳，包括蔣經國、李登輝、陳水扁總統、柴契爾夫人、戈巴契夫、張大千等，都曾是座上客。馥圓的靈魂人物是七十六歲的楊媽媽。從她五十四歲開始，及專注研究燕窩這道名菜，日本大飯店在去年元宵節前夕，更是特別請她飛一趟日本，為的就是品嘗她發的燕窩。 發燕窩有何學問？ 首先挑燕窩是一門學問，因為賣相越好的燕窩越有可能被動手腳，一整斤燕窩應該有色差才是天然未漂白，並且含水性約在百分之三十五之間，一些商人會塗膠鎖住水分、增加重量。以外型來看，窩形完整、窩碗大而肥厚、燕毛少、色潔白並透明、底座小為上品。上品燕窩發性強，發出來的量多；若燕窩色澤黃或是帶灰，摸起來又薄，漲性就不若前者。楊媽媽又特別注意底座部分，若底坐大，很可能是商人摻加碎燕窩、或是做果凍的燕菜，冒充重量。 發燕窩過程也是重頭戲，一斤燕窩成本五萬五千元，發到六、七斤，只有八十碗分量。如果發燕窩的功力不夠，就會蝕本。楊媽媽表示，在她一開始測試的四、五年間，很難控制燕窩的分量，像是以熱水發燕窩、泡的時間不夠。至於口感部分，泡水太久，燕窩糊了；換水次數不夠，燕窩會發出一股腥味。 日復一日，年復一年，她每天守著兩桶待發的燕窩與一本小冊子，紀錄發燕窩的變化，終於研發出夏天、冬天各要換幾次水，要浸泡多少的獨門心得。現在，只要天氣的溫度上升一度或下降一度，她就能精準而直覺的判斷出當天發燕窩的水溫該如何調整。「我不隨便、不馬虎、也不能『差不多』。這是我們二十幾年都不會被淘汰的菜。」楊媽媽笑著說。 有思想的髮型師 林錦惠每個一段時間就出國充電，客戶寧願等上七個月，也不願找別人 台北的高價髮廊－斐瑟的首席髮型設計師林錦惠也擁有同樣的專注特質，讓她在全台灣數萬名髮型師當中顯得突出。 走進髮廊，個子迷你的林錦惠正與其中一位顧客溝通造型。然而，在一旁乖乖等待她的客人多達六人，讓林錦惠剪一次頭髮要兩千五百元，這是一般髮型師的四倍，全台北市價錢在這之上的，不超過二十人。她的客人包括藝人張小燕、張清芳、庹宗康……等不計其數。一位電視台主播觀察，林錦惠的職業在社會上的地位或許不高，但她的年收入不見得少於中小企業的總經理。 「我從台中來，四個朋友包一車上來專給她剪，七點半就起床了。」葉太太說，她以前覺得自己剪法拉頭很漂亮，直到林錦惠分析她外型的優勢，才明白原來並不合適。「我台中的髮型設計師明天也要上來給錦惠剪。」她說。 在場的客人一聽林錦惠要被報導，人人搶著發言：「她很有想法，每次剪都不一樣」、「讓她剪完我會變得很有自信」、「剪完後平常不用花時間整理，六個月後還要回去剪時，竟有人問我是不是昨天剪完頭髮的，讓我很驚訝」……。五年以上的客人，一數竟有四位。從十五歲就找林錦惠、今年已二十五歲的林先生說：「我曾看過錦惠一天剪二、三十個人，但她對每一個人總是認真對待，剪得好的定義其實就是型不易走掉，而且她的資訊很快，足球明星貝克漢還沒紅到台灣的時候，她就已經在幫客人剪『貝克漢頭』了。」另一位宋小姐說，林錦惠很用功，常常出國取經，「我怕她不回來，沒天寫電子郵件與她保持聯絡，最後我足足等了七個月，忍耐讓頭髮留長，不敢給別人剪。」 認真，不斷的進修，是林錦惠保持決勝二十的秘訣。她永遠不滿足當下所擁有的技術。三十三歲的她每個一段時間就自費跑到歐洲、美國上課進修，最長的一次還花了一年時間待在紐約與倫敦，以至於存款所剩無幾。課程和美髮並無相關，而是去上塑膠、石油材質為主的雕塑課程。與髮型唯一相同的，是透過手的觸感，在硬和軟之間找到轉折點，臨場造一個型，並從中找出主題。她說：「原來的生活太安逸，若要產生髮的新意，就要來自心理上的衝突，所以我去看別人的生活、民情、態度，為什麼他們早上洗澡，為什麼他們的院子一定有燈？」她時常停下腳步，思考，沉澱，進步。 林錦惠順著自己的邏輯，將頭髮的元素拆、合、結構、建構，現在的她，連在餐廳裡看到香菇般的燈飾、樹上的葉子、光、水波、等著被切割的木頭，都能連接到頭髮裁剪時的創作。斐瑟髮廊負責人鄧泰華分析，林錦惠從剪一個頭六百元漲到今天的兩千五百元的身價，平均一個月仍有一百到一百五十個預約客人，證明她在做的是「一件有思想的工作」，而同期設計師常常自我設限。 強烈學習動機 彼得‧杜拉克：每兩年要更新專業知識，每四年要重新建立自己的基礎能力 「成功者會說，『我想找出一個可以使製作動畫更快的方法』，或者『我對怎樣黏合很有興趣』。」《財星》雜誌一九九五年訪問的南加州大學教授約翰‧古德曼(John Goodman)如此分析。這些人對於自己有興趣的領域，往往比別人多出千百倍的強烈學習動機，一在對自己有興趣的事物，追根究底、向下鑽研所得到的成就。 百分之二十的知識並不難取得，熱情、專注、堅持，重要的是不斷想要前進的心態。管理大師彼得‧杜拉克曾說：「一個人每兩年要更新專業知識，每四年要重新建立自己的基礎能力。」台灣IBM軟體事業處副總經理丁瑞麟也指出，知識經濟就是要從產能波走向腦力波，一個出類拔萃的員工必須把自己從過去的人力轉為人才，這兩者之間的差別，就是人才用心，且盡心盡力。 不過，大部分的人並不認為決勝在最後的百分之二十有什麼了不起，一些菜鳥總在學到百分之八十後振翅離去。 菜鳥與老鳥 菜鳥學到八十％常識後忙著飛走，老鳥不深思，輕易就被後進取代 杜書伍感慨的說：「他們廣而不精，就像走進吃到飽餐廳，東西很多每樣都吞。問他吃了沒有，都說吃到了。但問他味道好不好，卻說不出個什麼來，變成缺乏體悟，缺乏深度的現象。」去年，因為掌握到蕃茄汁趨勢的愛之味總裁陳哲芳也察覺到，一位成熟的企畫人員如果沒有五、六年的磨練，成不了最起碼的氣候。 另外一方面，一些老鳥的問題則在於不深思究竟自己學的是什麼，最後，成為裁員分波下的被淘汰的高危險群。杜書伍觀察：「有多數人永遠無法掌握專業的精髓，即使經過很長時間，能力依舊停在初學者的層級。此時只要來一位新人，稍加訓練，就可以輕易地將前面的人取代掉。」 就好像人生有許多知識水桶，到處亂飛的菜鳥每個水桶裝滿一半，不深思的老鳥則總是一個水桶都裝不滿，他們共有的最大問題就是認為自己：「已經學會了！」 ING安泰執行長潘燊昌在他的《聽老闆的，就錯了》書中提到：「年輕人不該擔心績效，而要擔心我今天做的事是不是跟昨天一樣。若工作十年只有一天經驗，還有什麼前途可言；而倚老賣老者最可憐，因為他們只有年齡『高人　一等』。」 等待的三十歲世代 在三十歲就停止思考、拒絕改變，從那是起就算已步入高年 大前研一在《工作雞湯》的兩集裡，都不約而同談起縱橫二十一世紀職場的成功秘訣。 他把日本職員三十五到五十歲稱為「魔力的十五年」。以一般日本企業而言，多數員工進入公司十年後大致已近三十五歲，此時多半已完全了解公司整體業務。 他指出，之後若沒有任何知識上的成長，那麼在公司將賦予重任的五十歲之前，大概只是從事例行工作。越是大型的企業，三十多歲的職員越容易成為一種所謂的「等待的三十歲年代」。從三十一到四十一歲的階段，多數人都在從事沒有變化與挑戰的例行工作，個人能力與知識相對不會有進步，這無異浪費了一生原本最具創造力與顛覆力的黃金時段。 「進入二十一世紀數位科技時代，若不能思變圖強，就是輸家。」他提到，日本人的平均壽命已延長為八十歲，但若在三十或四十就停止思考、拒絕改變，從那是起就算已步入高年。許多人拒絕改變的理由，竟是：「我已經大學畢業，受過高等教育。」 大前研一不僅批評這種心態，同時也提出了因應之道。 他認為，從學生時代一直接受單方面的僵化教育所產生的「資訊吸收型」頭腦，今後一定得想辦法轉變為「資訊發射型」頭腦。 這個頭腦必須對周遭不斷提出質疑，而質疑的先決條件，就是必須對各種事物保持興趣、強烈的好奇心與追根究柢的毅力與態度。 不過，在最初幾年的訓練過程，必須暫時拋棄所學的方法，一開始要盡量減少所接收的資訊，並鎖定單一的目標進行研究。若能持之以恆，相信五年後，就能成功轉變思考模式，建立獨立思考問題的習慣。 經驗快速貶值 今天的知識將成為明天的常識，知識怠惰者絕對無法生存 「我在麥肯錫的時候，經常提醒年輕人『知識怠惰者絕對無法生存』。」大前研一在書上強調今後將是「知識爆炸、經驗快速貶值」的時代。 因為今天的知識將成為明天的常識，兩者之間的分界線正在快速崩解、移動。匯豐直接投資亞洲有限公司董事長陳伯昌認為，建構知識的過程中，就像編織一張網，網織得越密，對世界的原貌、真理，掌握就越多。 年輕人常犯的毛病，就是網織的網洞很大、粗糙，才織一下，他們就認為可以了，拿著這張網去捕魚。結果，網洞太大，根本補不到什麼魚。所以一個人的知識網，應該是又細又廣。 建構知識像織網 陳伯昌：知識網不僅要又細又廣，跟要全面，才能勝任新的挑戰 不過，他也說，看看一些高階經理人，他們也許網織得又細又廣，但為什麼還是被淘汰？好比一個製造經理，他原本只管機器生產，等到升到副總，就開始必須了解原物料價格、供應商、必須管理人員、成本要低、產品品質要高、……。這個時候，他的知識網必須全面，不能片面的一張網就夠了。 陳伯昌看過一位財物副總，在公司裡一路擢昇上來，但是在企業開始走向國際化時碰到瓶頸，對於國際資本市場、大陸市場、與國外的會計師溝通、國外律師請教意見，甚至是國際的商業習慣，都無法勝任，最後集團老闆無法在重用他，從外面找來專家取代他的地位。這位財物副總大嘆「只見新人笑」，憤然離職。 這些因為知識網不夠全面而遭淘汰的高階經理人，每天都在發生，這些事情也非一朝一夕，而是有軌跡可循。學無止境，年輕的時候可能會有網織得不細的問題，等到年紀大了，若自己只有片面的網，也將勝任不了新的挑戰。 在瞬息萬變的時代裡，決勝二十％代表著時時保持唯恐落後的危機意識。如此，才能成為特定領域的頂尖人物。

母親的信念「一塊地，總有一粒種子適合它」

有一個女孩，沒考上大學，被安排在本村的小學教書。

由於講不清數學題，不到一週被學生轟下台。

母親為她擦了擦眼淚，安慰說，滿肚子的東西，有人倒得出來，有人倒不出來，沒必要為這個傷心，也許有更適合你的事情等著你去做。

後來，她又隨本村的夥伴一起外出打工。

不幸的是，她又被老闆轟了回來，原因是剪裁衣服的時候，手腳太慢了，品質也過不了關。母親對女兒說，手腳總是有快有慢，別人已經幹了很多年了，而你一直在念書，怎麼快得了？

女兒先後當過紡織工，幹過市場管理員，做過會計，但無一例外，都半途而廢。

然而每次女兒沮喪回來時，母親總安慰她，從沒有抱怨。

三十歲時，女兒憑著一點語言天賦，做了聾啞學校的輔導員。

後來，她又開辦了一家殘障學校，再後來，她在許多城市開辦了殘障人用品連鎖店，她已經是一個擁有幾千萬資產的老闆了。

有一天，功成名就的女兒湊到已經年邁的母親面前，她想得到一個一直以來想知道的答案。

那就是前些年她連連失敗，自己都覺得前途渺茫的時候，是什麼原因讓母親對她那麼有信心呢？

母親的回答樸素而簡單，她說，一塊地，不適合種麥子，可以試試種豆子；豆子也長不好的話，可以種瓜果；瓜果也不濟的話，撒上一些蕎麥種子一定能開花，因為一塊地，總有一粒種子適合它，也終會有屬於它的一片收成。

聽完母親的話，女兒落淚了，她明白了，實際上，母親恆久而不絕的信念和愛，就是一粒堅韌的種子；她的奇蹟，就是這粒種子執著而生長出的奇蹟。