一个类不能被继承，也就是说它的子类不能构造父类，这样子类就没有办法实例化整个子类从而实现子类无法继承父类。我们可以将一个类的构造函数声明为私有，使得这个类的构造函数对子类不可见，那么这个类也就不能继承了。但是，这引出一个问题，客户程序岂不是也无法实例化这个类了？OK，让我们参考一下Singleton模式，用一个static函数来帮助创建这个类的实例，问题就解决了！

class CParent
{
private:
    CParent(int v){m_v = v;}
    ~CParent(){}

    int m_v;
    static CParent * m_instance;
public:
void fun(){cout << "The value is: " << m_v << endl;}
    static CParent * getInstance(int v);
};
CParent * CParent::m_instance = NULL;

CParent * CParent::getInstance(int v)
{
    m_instance = new CParent(v);
    return m_instance;
}

         这是一个有效的方法，但是static函数创建出来的实例必然是static的。而且，这个类不能像普通的类那样构建对象，比如：

CParent c;  // impossible

换个思路考虑一下，友元不也是不能被继承的么？我们可以把类的构造函数定义为private的同时，定义友元函数来帮助构造类的实例。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/lazy_tiger/archive/2008/03/28/2224899.aspx

论函数调用约定
　　在C语言中，假设我们有这样的一个函数：
　　
　　int function(int a,int b)
　　
　　调用时只要用result = function(1,2)这样的方式就可以使用这个函数。但是，当高级语言被编译成计算机可以识别的机器码时，有一个问题就凸现出来：在CPU中，计算机没有办法知道一个函数调用需要多少个、什么样的参数，也没有硬件可以保存这些参数。也就是说，计算机不知道怎么给这个函数传递参数，传递参数的工作必须由函数调用者和函数本身来协调。为此，计算机提供了一种被称为栈的数据结构来支持参数传递。

　　栈是一种先进后出的数据结构，栈有一个存储区、一个栈顶指针。栈顶指针指向堆栈中第一个可用的数据项（被称为栈顶）。用户可以在栈顶上方向栈中加入数据，这个操作被称为压栈(Push)，压栈以后，栈顶自动变成新加入数据项的位置，栈顶指针也随之修改。用户也可以从堆栈中取走栈顶，称为弹出栈(pop)，弹出栈后，栈顶下的一个元素变成栈顶，栈顶指针随之修改。

　　函数调用时，调用者依次把参数压栈，然后调用函数，函数被调用以后，在堆栈中取得数据，并进行计算。函数计算结束以后，或者调用者、或者函数本身修改堆栈，使堆栈恢复原装。

　　在参数传递中，有两个很重要的问题必须得到明确说明：
　　
　　当参数个数多于一个时，按照什么顺序把参数压入堆栈
　　函数调用后，由谁来把堆栈恢复原装
　　在高级语言中，通过函数调用约定来说明这两个问题。常见的调用约定有：

　　stdcall
　　cdecl
　　fastcall
　　thiscall
　　naked call

　　stdcall调用约定
　　stdcall很多时候被称为pascal调用约定，因为pascal是早期很常见的一种教学用计算机程序设计语言，其语法严谨，使用的函数调用约定就是stdcall。在Microsoft C++系列的C/C++编译器中，常常用PASCAL宏来声明这个调用约定，类似的宏还有WINAPI和CALLBACK。

　　stdcall调用约定声明的语法为(以前文的那个函数为例）：
　　
　　int __stdcall function(int a,int b)
　　
　　stdcall的调用约定意味着：1）参数从右向左压入堆栈，2）函数自身修改堆栈 3)函数名自动加前导的下划线，后面紧跟一个@符号，其后紧跟着参数的尺寸

　　以上述这个函数为例，参数b首先被压栈，然后是参数a，函数调用function(1,2)调用处翻译成汇编语言将变成：

　　push 2　　　　　　　 第二个参数入栈
　　push 1　　　　　　　 第一个参数入栈
　　call function　　　　调用参数，注意此时自动把cs:eip入栈

　　而对于函数自身，则可以翻译为：
　　push ebp　　　　　　 保存ebp寄存器，该寄存器将用来保存堆栈的栈顶指针，可以在函数退出时恢复
　　mov　ebp, esp　　　　保存堆栈指针
　　mov　eax,[ebp + 8H]　堆栈中ebp指向位置之前依次保存有ebp, cs:eip, a, b, ebp +8指向a
　　add　eax,[ebp + 0CH] 堆栈中ebp + 12处保存了b
　　mov　esp, ebp　　　　恢复esp
　　pop　ebp
　　ret　8

　　而在编译时，这个函数的名字被翻译成_function@8

　　注意不同编译器会插入自己的汇编代码以提供编译的通用性，但是大体代码如此。其中在函数开始处保留esp到ebp中，在函数结束恢复是编译器常用的方法。

　　从函数调用看，2和1依次被push进堆栈，而在函数中又通过相对于ebp(即刚进函数时的堆栈指针）的偏移量存取参数。函数结束后，ret 8表示清理8个字节的堆栈，函数自己恢复了堆栈。

　　
　　cdecl调用约定
　　cdecl调用约定又称为C调用约定，是C语言缺省的调用约定，它的定义语法是：

　　int function (int a ,int b)　//不加修饰就是C调用约定
　　int __cdecl function(int a,int b)//明确指出C调用约定

　　在写本文时，出乎我的意料，发现cdecl调用约定的参数压栈顺序是和stdcall是一样的，参数首先由右向左压入堆栈。所不同的是，函数本身不清理堆栈，调用者负责清理堆栈。由于这种变化，C调用约定允许函数的参数的个数是不固定的，这也是C语言的一大特色。对于前面的function函数，使用cdecl后的汇编码变成：

　　调用处
　　push 1
　　push 2
　　call function
　　add　esp, 8　　　　　注意：这里调用者在恢复堆栈

　　被调用函数_function处
　　push ebp　　　　　　 保存ebp寄存器，该寄存器将用来保存堆栈的栈顶指针，可以在函数退出时恢复
　　mov　ebp,esp　　　　 保存堆栈指针
　　mov　eax,[ebp + 8H]　堆栈中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向a
　　add　eax,[ebp + 0CH] 堆栈中ebp + 12处保存了b
　　mov　esp,ebp　　　　 恢复esp
　　pop　ebp
　　ret　　　　　　　　　注意，这里没有修改堆栈

　　MSDN中说，该修饰自动在函数名前加前导的下划线，因此函数名在符号表中被记录为_function，但是我在编译时似乎没有看到这种变化。

　　由于参数按照从右向左顺序压栈，因此最开始的参数在最接近栈顶的位置，因此当采用不定个数参数时，第一个参数在栈中的位置肯定能知道，只要不定的参数个数能够根据第一个后者后续的明确的参数确定下来，就可以使用不定参数，例如对于CRT中的sprintf函数，定义为：
　　int sprintf(char* buffer,const char* format,...)
　　由于所有的不定参数都可以通过format确定，因此使用不定个数的参数是没有问题的。

　　fastcall
　　fastcall调用约定和stdcall类似，它意味着：
　　
　　函数的第一个和第二个DWORD参数（或者尺寸更小的）通过ecx和edx传递，其他参数通过从右向左的顺序压栈
　　被调用函数清理堆栈
　　函数名修改规则同stdcall
　　其声明语法为：int fastcall function(int a, int b)

　　thiscall
　　thiscall是唯一一个不能明确指明的函数修饰，因为thiscall不是关键字。它是C++类成员函数缺省的调用约定。由于成员函数调用还有一个this指针，因此必须特殊处理，thiscall意味着：

　　参数从右向左入栈
　　如果参数个数确定，this指针通过ecx传递给被调用者；如果参数个数不确定，this指针在所有参数压栈后被压入堆栈。对参数个数不定的，调用者清理堆栈，否则函数自己清理堆栈为了说明这个调用约定，定义如下类和使用代码：

　　class A
　　{
　　public:
　　　 int function1(int a,int b);
　　　 int function2(int a,...);
　　};

　　int A::function1 (int a,int b)
　　{
　　　 return a+b;
　　}

　　#include <stdarg.h>
　　int A::function2(int a,...)
　　{
　　　 va_list ap;
　　　 va_start(ap,a);
　　　 int i;
　　　 int result = 0;
　　　 for(i = 0 ; i < a ; i ++)
　　　 {
　　　　　result += va_arg(ap,int);
　　　 }
　　　 return result;
　　}

　　void callee()
　　{
　　　 A a;
　　　 a.function1(1, 2);
　　　 a.function2(3, 1, 2, 3);
　　}

callee函数被翻译成汇编后就变成：
　　//函数function1调用
　　00401C1D　 push　　　　2
　　00401C1F　 push　　　　1
　　00401C21　 lea　　　　 ecx,[ebp-8]
　　00401C24　 call　　　　function1　　　　　注意，这里this没有被入栈

　　//函数function2调用
　　00401C29　 push　　　　3
　　00401C2B　 push　　　　2
　　00401C2D　 push　　　　1
　　00401C2F　 push　　　　3
　　00401C31　 lea　　　　 eax, [ebp-8]　　　 这里引入this指针
　　00401C34　 push　　　　eax
　　00401C35　 call　　　　function2
　　00401C3A　 add　　　　 esp, 14h
　　
　　可见，对于参数个数固定情况下，它类似于stdcall，不定时则类似cdecl

　　naked call
　　这是一个很少见的调用约定，一般程序设计者建议不要使用。编译器不会给这种函数增加初始化和清理代码，更特殊的是，你不能用return返回返回值，只能用插入汇编返回结果。这一般用于实模式驱动程序设计，假设定义一个求和的加法程序，可以定义为：

　　__declspec(naked) int　add(int a,int b)
　　{
　　　 __asm mov eax,a
　　　 __asm add eax,b
　　　 __asm ret
　　}

　　注意，这个函数没有显式的return返回值，返回通过修改eax寄存器实现，而且连退出函数的ret指令都必须显式插入。上面代码被翻译成汇编以后变成：

　　mov eax,[ebp+8]
　　add eax,[ebp+12]
　　ret 8

　 注意这个修饰是和__stdcall及cdecl结合使用的，前面是它和cdecl结合使用的代码，对于和stdcall结合的代码，则变成：

　　__declspec(naked) int __stdcall function(int a,int b)
　 {
　　　　__asm mov eax,a
　　　　__asm add eax,b
　　　　__asm ret 8　　　　//注意后面的8
　　}

　　至于这种函数被调用，则和普通的cdecl及stdcall调用函数一致。

　　函数调用约定导致的常见问题
　　如果定义的约定和使用的约定不一致，则将导致堆栈被破坏，导致严重问题，下面是两种常见的问题：

　　函数原型声明和函数体定义不一致
　　DLL导入函数时声明了不同的函数约定
　　以后者为例，假设我们在dll种声明了一种函数为：

　　__declspec(dllexport) int func(int a,int b);//注意，这里没有stdcall，使用的是cdecl
　　使用时代码为：

　　typedef int (*WINAPI DLLFUNC)func(int a,int b);
　　hLib = LoadLibrary(...);

　　DLLFUNC func = (DLLFUNC)GetProcAddress(...)//这里修改了调用约定
　　result = func(1,2);//导致错误

　　由于调用者没有理解WINAPI的含义错误的增加了这个修饰，上述代码必然导致堆栈被破坏，MFC在编译时插入的checkesp函数将告诉你，堆栈被破坏
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fly2k5/archive/2005/12/05/544112.aspx

SQL code

create table AAA(ID INT,strNum1 varchar(8),strNum2 varchar(8),intTaxis int) 
insert into AAA select 1,'01' ,'001',1
insert into AAA select 2,'001','011',2 
insert into AAA select 3,'001','010',1 
insert into AAA select 6,'01' ,'002',2 
insert into AAA select 4,'002','021',1 
insert into AAA select 5,'002','022',2 
go

--创建用户定义函数
create function f_getChild(@strNum1 VARCHAR(10))
returns @t table(strNum1 VARCHAR(10),strNum2 VARCHAR(10),Level INT,Ord varchar(100))
as
begin
    declare @i int
    set @i=1
    insert into @t select strNum1,strNum2,@i,right('0'+strNum2,3) from AAA where strNum1 = @strNum1
    
    while @@rowcount<>0
    begin
        set @i=@i+1
        insert into @t 
        select 
            a.strNum1,a.strNum2,@i,b.Ord+a.strNum2
        from 
            AAA a,@t b 
        where 
            a.strNum1=b.strNum2 and b.Level=@i-1
            and
            not exists(select 1 from @t where strNum1=a.strNum1 and strNum2=a.strNum2)
    end
    return
end
go

--执行查询
select * from dbo.f_getChild('01') order by Ord
go

--输出结果
/*
strNum1    strNum2    Level       Ord
---------- ---------- ----------- -----------
01         001        1           001
001        010        2           001010
001        011        2           001011
01         002        1           002
002        021        2           002021
002        022        2           002022
*/

--删除测试数据
drop function f_getChild
drop table AAA
go

　　SQLServer2005的Non-clustered INDEX增加了一个“包含列(included column) ”选项。在 SQL Server 2005 中，可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能。通过包含非键列，可以创建覆盖更多查询的非聚集索引。当查询中的所有列都作为键列或非键列包含在索引中时，带有包含性非键列的索引可以显著提高查询性能。这样可以实现性能提升，因为查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。

　　但应避免添加不必要的列。添加过多的索引列（键列或非键列）会对性能产生不良影响，应该合理使用。和Clustered INDEX，或者组合索引，结合使用，扩大索引覆盖，但不大可能所有列都有索引覆盖，磁盘开销和数据insert updat时索引的重新计算的时间开销是巨大的。总之，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。

　　继续实践，先建个实验表 Table1：

　　建两个索引：

　　1. 主键ID是Clustered INDEX

　　2. 非聚簇索引Non-Clustered INDEX建立在Age列上，包含列：Count。

CREATE　NONCLUSTERED　INDEX　[cnt]　ON　[dbo].[table1]　
(　
　　　　[Age]　ASC　
)　
INCLUDE　(　[Count])　
ON　[PRIMARY]

　　我们的测试SQL语句是：从10万条记录中取出4条记录，两种写法

　　1. SELECT * FROM table1 WHERE age < 100;

　　2. SELECT count FROM table1 WHERE age < 100;

　　看看运行效率如何：

　　磁盘IO和时间：

　　实际执行计划：

　　性能居然相差20多倍。为什么？

　　原来第二句Select Count在索引覆盖范围内，因为查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。而第一句Select * 选择了所有字段，其中有一个字段Name不在索引覆盖范围内（既不在聚簇索引列，也不在非聚簇索引覆盖列内），而一次查询对于一个数据表只能使用一个索引，多个索引是无法使用叠加的。查询分析优化器必须进行选择, 上述执行计划就是优化的结果，依然比第二个index seek慢了20倍。

　　然后我又把sql改了一下，变成从10万条记录中取得大部分数据( 返回99900条)，小于号改成大于号：

　　1. SELECT * FROM table1 WHERE age > 100;

　　2. SELECT count FROM table1 WHERE age > 100;

　　看看结果：

　　磁盘IO和时间：

　　实际执行计划：

　　依然是第二句索引覆盖的快，这是毋庸置疑的。但第一句执行计划有所不同，SQLServer查询分析优化器选择了不同的策略，改为聚簇索引扫描。上面说过了，一次查询对于一个数据表只能使用一个索引，多个索引是无法使用叠加的。查询分析优化器必须进行选择, 上述执行计划就是优化的结果。但为何SQLServer统计了结果集就非常智能的选择了这个方案，恐怕要等高手来解释了。

　　看到这儿，恐怕喜欢用Select*的同学也要节制一下使用了，有时候SQLServer中Select*代价是很高的。当然类似这种SQL是没有问题的，（where exists (select * from ...)），因为SQLServer查询分析优化器会聪明的知道此Select*非彼Select*。

　　数据库是一个很复杂的系统，即使你不是数据库专家，是应用开发人员，知道一点SQLServer内部更多的东西会有好处，而合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来, 才能产生最佳的优化方案。

　　数据库性能优化中索引绝对是一个重量级的因素，可以说，索引使用不当，其它优化措施将毫无意义。

　　聚簇索引(Clustered Index)和非聚簇索引 (Non- Clustered Index)　

　　最通俗的解释是:聚簇索引的顺序就是数据的物理存储顺序，而对非聚簇索引的索引顺序与数据物理排列顺序无关。举例来说，你翻到新华字典的汉字“爬”那一页就是P开头的部分，这就是物理存储顺序（聚簇索引）；而不用你到目录，找到汉字“爬”所在的页码，然后根据页码找到这个字（非聚簇索引）。

　　下表给出了何时使用聚簇索引与非聚簇索引:

动作	使用聚簇索引	使用非聚簇索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

　　聚簇索引的唯一性

　　正式聚簇索引的顺序就是数据的物理存储顺序，所以一个表最多只能有一个聚簇索引，因为物理存储只能有一个顺序。正因为一个表最多只能有一个聚簇索引，所以它显得更为珍贵，一个表设置什么为聚簇索引对性能很关键。

　　初学者最大的误区：把主键自动设为聚簇索引

　　因为这是SQLServer的默认主键行为，你设置了主键，它就把主键设为聚簇索引，而一个表最多只能有一个聚簇索引，所以很多人就把其他索引设置为非聚簇索引。这个是最大的误区。甚至有的主键又是无意义的自动增量字段，那样的话Clustered index对效率的帮助，完全被浪费了。

　　刚才说到了，聚簇索引性能最好而且具有唯一性，所以非常珍贵，必须慎重设置。一般要根据这个表最常用的SQL查询方式来进行选择，某个字段作为聚簇索引，或组合聚簇索引，这个要看实际情况。

　　事实上，建表的时候，先需要设置主键，然后添加我们想要的聚簇索引，最后设置主键，SQLServer就会自动把主键设置为非聚簇索引（会自动根据情况选择）。如果你已经设置了主键为聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可。

　　记住我们的最终目的就是在相同结果集情况下，尽可能减少逻辑IO。

　　我们先从一个实际使用的简单例子开始。

　　一个简单的表：

CREATE　TABLE　[dbo].[Table1](
　　[ID]　[int]　IDENTITY(1,1)　NOT　NULL,
　　[Data1]　[int]　NOT　NULL　DEFAULT　((0)),
　　[Data2]　[int]　NOT　NULL　DEFAULT　((0)),
　　[Data3]　[int]　NOT　NULL　DEFAULT　((0)),
　　[Name1]　[nvarchar](50)　NOT　NULL　DEFAULT　(''),
　　[Name2]　[nvarchar](50)　NOT　NULL　DEFAULT　(''),
　　[Name3]　[nvarchar](50)　DEFAULT　(''),
　　[DTAt]　[datetime]　NOT　NULL　DEFAULT　(getdate())

　　来点测试数据（10w条）：

declare　@i　int
set　@i　=　1　
while　@i　<　100000　
begin　
insert　into　Table1　([Data1]　,[Data2]　,[Data3]　,[Name1],[Name2]　,[Name3])　
values(@i,　2*　@i,3*@i,　CAST(@i　AS　NVARCHAR(50)),　CAST(2*@i　AS　NVARCHAR(50)),　CAST(3*@i　AS　NVARCHAR(50)))
set　@i　=　@i　+　1
end
update　table1　set　dtat=　DateAdd　(s,　data1,　dtat)

　　打开查询分析器的IO统计和时间统计：

SET　STATISTICS　IO　ON;
SET　STATISTICS　TIME　ON;

　　显示实际的“执行计划”：

　　我们最常用的SQL查询是这样的：

SELECT　*　FROM　Table1　WHERE　Data1　=　2　ORDER　BY　DTAt　DESC;

　　先在Table1设主键ID，系统自动为该主键建立了聚簇索引。

　　然后执行该语句，结果是：

Table　'Table1'.　Scan　count　1,　logical　reads　911,　physical　reads　0,　read-ahead　reads　0,　lob　logical　reads　0,　lob　physical　reads　0,　lob　read-ahead　reads　0.
SQL　Server　Execution　Times:
CPU　time　=　16　ms,　elapsed　time　=　7　ms.

　　然后我们在Data1和DTat字段分别建立非聚簇索引：

CREATE　NONCLUSTERED　INDEX　[N_Data1]　ON　[dbo].[Table1]　
(
[Data1]　ASC
)WITH　(SORT_IN_TEMPDB　=　OFF,　DROP_EXISTING　=　OFF,　IGNORE_DUP_KEY　=　OFF,　ONLINE　=　OFF)　ON　[PRIMARY]
CREATE　NONCLUSTERED　INDEX　[N_DTat]　ON　[dbo].[Table1]　
(
[DTAt]　ASC
)WITH　(SORT_IN_TEMPDB　=　OFF,　DROP_EXISTING　=　OFF,　IGNORE_DUP_KEY　=　OFF,　ONLINE　=　OFF)　ON　[PRIMARY]

　　再次执行该语句，结果是：

Table　'Table1'.　Scan　count　1,　logical　reads　5,　physical　reads　0,　read-ahead　reads　0,　lob　logical　reads　0,　lob　physical　reads　0,　lob　read-ahead　reads　0.
SQL　Server　Execution　Times:
CPU　time　=　0　ms,　elapsed　time　=　39　ms.

　　图片看不清楚？请点击这里查看原图（大图）。

　　可以看到设立了索引反而没有任何性能的提升而且消耗的时间更多了，继续调整。

　　然后我们删除所有非聚簇索引，并删除主键，这样所有索引都删除了。建立组合索引Data1和DTAt，最后加上主键：

CREATE　CLUSTERED　INDEX　[C_Data1_DTat]　ON　[dbo].[Table1]　
(
[Data1]　ASC,
[DTAt]　ASC
)WITH　(SORT_IN_TEMPDB　=　OFF,　DROP_EXISTING　=　OFF,　IGNORE_DUP_KEY　=　OFF,　ONLINE　=　OFF)　ON　[PRIMARY]

　　再次执行语句：

Table　'Table1'.　Scan　count　1,　logical　reads　3,　physical　reads　0,　read-ahead　reads　0,　lob　logical　reads　0,　lob　physical　reads　0,　lob　read-ahead　reads　0.
SQL　Server　Execution　Times:
CPU　time　=　0　ms,　elapsed　time　=　1　ms.

　　可以看到只有聚簇索引seek了，消除了index scan和nested loop，而且执行时间也只有1ms，达到了最初优化的目的。

　　组合索引小结

　　小结以上的调优实践，要注意聚簇索引的选择。首先我们要找到我们最多用到的SQL查询，像本例就是那句类似的组合条件查询的情况，这种情况最好使用组合聚簇索引，而且最多用到的字段要放在组合聚簇索引的前面，否则的话就索引就不会有好的效果，看下例：

　　图片看不清楚？请点击这里查看原图（大图）。

　　查询条件落在组合索引的第二个字段上，引起了index scan，效果很不好，执行时间是：

Table　'Table1'.　Scan　count　1,　logical　reads　238,　physical　reads　0,　read-ahead　reads　0,　lob　logical　reads　0,　lob　physical　reads　0,　lob　read-ahead　reads　0.
SQL　Server　Execution　Times:
CPU　time　=　16　ms,　elapsed　time　=　22　ms.

　　而如果仅查询条件是第一个字段也没有问题，因为组合索引最左前缀原则，实践如下：

Table　'Table1'.　Scan　count　1,　logical　reads　3,　physical　reads　0,　read-ahead　reads　0,　lob　logical　reads　0,　lob　physical　reads　0,　lob　read-ahead　reads　0.
SQL　Server　Execution　Times:
CPU　time　=　0　ms,　elapsed　time　=　1　ms.

　　从中可以看出，最多用到的字段要放在组合聚簇索引的前面。

　　Index seek 为什么比 Index scan好？

　　索引扫描也就是遍历B树，而seek是B树查找直接定位。

　　Index scan多半是出现在索引列在表达式中。数据库引擎无法直接确定你要的列的值，所以只能扫描整个整个索引进行计算。index seek就要好很多.数据库引擎只需要扫描几个分支节点就可以定位到你要的记录。回过来,如果聚集索引的叶子节点就是记录，那么Clustered Index Scan就基本等同于full table scan。

　　一些优化原则

　　1、缺省情况下建立的索引是非聚簇索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
a.有大量重复值、且经常有范围查询（ > ,< ，> =,< =）和order by、group by发生的列，可考
虑建立群集索引；
b.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
c.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。
2、ORDER BY和GROPU BY使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。

　　3、多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。
4、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
5、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。

　　Sql的优化原则2：
1、只要能满足你的需求，应尽可能使用更小的数据类型：例如使用MEDIUMINT代替INT
2、尽量把所有的列设置为NOT NULL，如果你要保存NULL，手动去设置它，而不是把它设为默认值。
3、尽量少用VARCHAR、TEXT、BLOB类型
4、如果你的数据只有你所知的少量的几个。最好使用ENUM类型　
　

　　有关Join的一些原则

　　SQL Server 有三种类型的JOIN操作：

　　Nested loops joins

　　Merge joins

　　Hash joins

　　如果Join的输入很小，例如小于10行，然后其他的Join输入很大并且索引在其列上，则Nested loops joins是最快的。（原因参考Understanding Nested Loops Joins）

　　如果两个Join输入都不小，但在索引列上排序（例如是在扫描排序的索引后获得的 scanning sorted indexes），则Merge joins是最快的。（原因参考Understanding Merge Joins）

　　Hash joins可以有效的处理大量的、没有排序的、没有索引的输入。尤其对复杂查询的中间结果处理很有效。（更多参考Understanding Hash Joins）

　　如何分析SQL语句

　　微软MSDN给出了答案：http://msdn.microsoft.com/en-us/library/ms191227.aspx

　　找出数据库中性能最差的SQL

　　优化哪个表？从何入手？首先需要定位性能瓶颈，找到运行最慢的SQL。可以采用如下步骤：

　　1. 运行 dbcc　 freeProcCache　 清除缓存

　　2. 运行你的程序，或者你的SQL或存储过程，操作数据库

　　3. 完了以后运行以下SQL找到运行最慢的SQL：

SELECT　　DB_ID(DB.dbid)　'数据库名'　
　　　　　　,　OBJECT_ID(db.objectid)　'对象'　
　　　　　　,　QS.creation_time　'编译计划的时间'　
　　　　　　,　QS.last_execution_time　'上次执行计划的时间'　
　　　　　　,　QS.execution_count　'执行的次数'　
　　　　　　,　QS.total_elapsed_time　/　1000　'占用的总时间（秒）'　
　　　　　　,　QS.total_physical_reads　'物理读取总次数'　
　　　　　　,　QS.total_worker_time　/　1000　'CPU　时间总量（秒）'　
　　　　　　,　QS.total_logical_writes　'逻辑写入总次数'　
　　　　　　,　QS.total_logical_reads　N'逻辑读取总次数'　
　　　　　　,　QS.total_elapsed_time　/　1000　N'总花费时间（秒）'　
　　　　　　,　SUBSTRING(ST.text,　(　QS.statement_start_offset　/　2　)　+　1,　
　　　　　　　　　　　　　　　　　　(　(　CASE　statement_end_offset　
　　　　　　　　　　　　　　　　　　　　　　　　WHEN　-1　THEN　DATALENGTH(st.text)　
　　　　　　　　　　　　　　　　　　　　　　　　ELSE　QS.statement_end_offset　
　　　　　　　　　　　　　　　　　　　　　　END　-　QS.statement_start_offset　)　/　2　)　+　1)　AS　'执行语句'　
FROM　　　　sys.dm_exec_query_stats　AS　QS　CROSS　APPLY　
　　　　　　　　sys.dm_exec_sql_text(QS.sql_handle)　AS　ST　INNER　JOIN　
　　　　　　　　(　SELECT　　　　*　
　　　　　　　　　　FROM　　　　　　sys.dm_exec_cached_plans　cp　CROSS　APPLY　
　　　　　　　　　　　　　　　　　　　　sys.dm_exec_query_plan(cp.plan_handle)　
　　　　　　　　)　DB　
　　　　　　　　　　　　ON　QS.plan_handle　=　DB.plan_handle　
where　　　SUBSTRING(st.text,　(　qs.statement_start_offset　/　2　)　+　1,　
　　　　　　　　　　　　　　　　　　(　(　CASE　statement_end_offset　
　　　　　　　　　　　　　　　　　　　　　　　　WHEN　-1　THEN　DATALENGTH(st.text)　
　　　　　　　　　　　　　　　　　　　　　　　　ELSE　qs.statement_end_offset　
　　　　　　　　　　　　　　　　　　　　　　END　-　qs.statement_start_offset　)　/　2　)　+　1)　not　like　'%fetch%'　
　　　　　　　　　　　　　　　　　　　　　　ORDER　BY　QS.total_elapsed_time　/　1000　DESC　

　　使用SQLServer Profiler找出数据库中性能最差的SQL

　　首先打开SQLServer Profiler:

　　然后点击工具栏“New Trace”，使用默认的模板，点击RUN。

　　也许会有报错："only TrueType fonts are supported. There id not a TrueType font"。不用怕，点击Tools菜单->Options，重新选择一个字体例如Vendana 即可。（这个是微软的一个bug）

　　运行起来以后，SQLServer Profiler会监控数据库的活动，所以最好在你需要监控的数据库上多做些操作。等觉得差不多了，点击停止。然后保存trace结果到文件或者table。

　　这里保存到Table：在菜单“File”-“Save as ”-“Trace table”，例如输入一个master数据库的新的table名：profileTrace，保存即可。

　　找到最耗时的SQL：

use　master
select　*　from　profiletrace　order　by　duration　desc;

　　找到了性能瓶颈，接下来就可以有针对性的一个个进行调优了。

　　对使用SQLServer Profiler的更多信息可以参考：

　　http://www.codeproject.com/KB/database/DiagnoseProblemsSQLServer.aspx

　　使用SQLServer Database Engine Tuning Advisor数据库引擎优化顾问

　　使用上述的SQLServer Profiler得到了trace还有一个好处就是可以用到这个优化顾问。用它可以偷点懒，得到SQLServer给您的优化顾问，例如这个表需要加个索引什么的…

　　首先打开数据库引擎优化顾问：

　　然后打开刚才profiler的结果（我们存到了master数据库的profileTrace表）：

　　图片看不清楚？请点击这里查看原图（大图）。

　　点击“start analysis”，运行完成后查看优化建议（图中最后是建议建立的索引，性能提升72%）

　　图片看不清楚？请点击这里查看原图（大图）。

　　这个方法可以偷点懒，得到SQLServer给您的优化顾问。

A named pipe client uses the CreateFile function to open a handle to a named pipe. If the pipe exists but all of its instances are busy, CreateFile returns zero and the GetLastError function returns ERROR_PIPE_BUSY. When this happens, the named pipe client uses the WaitNamedPipe function to wait for an instance of the named pipe to become available.

The CreateFile function fails if the access specified is incompatible with the access specified (duplex, outbound, or inbound) when the server created the pipe. For a duplex pipe, the client can specify read, write, or read/write access; for an outbound pipe (write-only server), the client must specify read-only access; and for an inbound pipe (read-only server), the client must specify write-only access.

The handle returned by CreateFile defaults to byte-read mode, blocking-wait mode, overlapped mode disabled, and write-through mode disabled. The pipe client can use CreateFile to enable overlapped mode by specifying FILE_FLAG_OVERLAPPED or to enable write-through mode by specifying FILE_FLAG_WRITE_THROUGH. The client can use the SetNamedPipeHandleState function to enable nonblocking mode by specifying PIPE_NOWAIT or to enable message-read mode by specifying PIPE_READMODE_MESSAGE.

The following example shows a pipe client that opens a named pipe, sets the pipe handle to message-read mode, uses the WriteFile function to send a request to the server, and uses the ReadFile function to read the server's reply. This pipe client can be used with any of the message-type servers listed at the bottom of this topic. With a byte-type server, however, this pipe client fails when it calls SetNamedPipeHandleState to change to message-read mode. Because the client is reading from the pipe in message-read mode, it is possible for the ReadFile operation to return zero after reading a partial message. This happens when the message is larger than the read buffer. In this situation, GetLastError returns ERROR_MORE_DATA, and the client can read the remainder of the message using additional calls to ReadFile.

This pipe client can be used with any of the pipe servers listed under See Also.

#include <windows.h>
#include <stdio.h>
#include <conio.h>
#include <tchar.h>
#define BUFSIZE 512
int _tmain(int argc, TCHAR *argv[])
{
HANDLE hPipe;
LPTSTR lpvMessage=TEXT("Default message from client");
TCHAR chBuf[BUFSIZE];
BOOL fSuccess;
DWORD cbRead, cbWritten, dwMode;
LPTSTR lpszPipename = TEXT("\\\\.\\pipe\\mynamedpipe");
if( argc > 1 )
lpvMessage = argv[1];
// Try to open a named pipe; wait for it, if necessary.
while (1)
{
hPipe = CreateFile(
lpszPipename,   // pipe name
GENERIC_READ |  // read and write access
GENERIC_WRITE,
0,              // no sharing
NULL,           // default security attributes
OPEN_EXISTING,  // opens existing pipe
0,              // default attributes
NULL);          // no template file
// Break if the pipe handle is valid.
if (hPipe != INVALID_HANDLE_VALUE)
break;
// Exit if an error other than ERROR_PIPE_BUSY occurs.
if (GetLastError() != ERROR_PIPE_BUSY)
{
printf("Could not open pipe");
return 0;
}
// All pipe instances are busy, so wait for 20 seconds.
if (!WaitNamedPipe(lpszPipename, 20000))
{
printf("Could not open pipe");
return 0;
}
}
// The pipe connected; change to message-read mode.
dwMode = PIPE_READMODE_MESSAGE;
fSuccess = SetNamedPipeHandleState(
hPipe,    // pipe handle
&dwMode,  // new pipe mode
NULL,     // don't set maximum bytes
NULL);    // don't set maximum time
if (!fSuccess)
{
printf("SetNamedPipeHandleState failed");
return 0;
}
// Send a message to the pipe server.
fSuccess = WriteFile(
hPipe,                  // pipe handle
lpvMessage,             // message
(lstrlen(lpvMessage)+1)*sizeof(TCHAR), // message length
&cbWritten,             // bytes written
NULL);                  // not overlapped
if (!fSuccess)
{
printf("WriteFile failed");
return 0;
}
do
{
// Read from the pipe.
fSuccess = ReadFile(
hPipe,    // pipe handle
chBuf,    // buffer to receive reply
BUFSIZE*sizeof(TCHAR),  // size of buffer
&cbRead,  // number of bytes read
NULL);    // not overlapped
if (! fSuccess && GetLastError() != ERROR_MORE_DATA)
break;
_tprintf( TEXT("%s\n"), chBuf );
} while (!fSuccess);  // repeat loop if ERROR_MORE_DATA
getch();
CloseHandle(hPipe);
return 0;
}

转载请注明出处http://www.cppblog.com/greatws/archive/2008/08/31/60546.html

最近有人问我关于这个的问题，就此写一篇blog

Ansi字符串我们最熟悉，英文占一个字节，汉字2个字节，以一个\0结尾，常用于txt文本文件
Unicode字符串，每个字符(汉字、英文字母)都占2个字节，以2个连续的\0结尾，NT操作系统内核用的是这种字符串，常被定义为typedef unsigned short wchar_t;所以我们有时常会见到什么char*无法转换为unsigned short*之类的错误，其实就是unicode
UTF8是Unicode一种压缩形式，英文A在unicode中表示为0x0041，老外觉得这种存储方式太浪费，因为浪费了50%的空间，于是就把英文压缩成1个字节，成了utf8编码，但是汉字在utf8中占3个字节，显然用做中文不如ansi合算，这就是中国的网页用作ansi编码而老外的网页常用utf8的原因。
UTF8在还游戏里运用的很广泛，比如WOW的lua脚本等

下面来说一下转换，主要用代码来说明吧
写文件我用了CFile类，其实用FILE*之类的也是一样，写文件和字符串什么类别没有关系，硬件只关心数据和长度

Ansi转Unicode
介绍2种方法

void CConvertDlg::OnBnClickedButtonAnsiToUnicode()
{
    // ansi to unicode
    char* szAnsi = "abcd1234你我他";
    //预转换，得到所需空间的大小
    int wcsLen = ::MultiByteToWideChar(CP_ACP, NULL, szAnsi, strlen(szAnsi), NULL, 0);
    //分配空间要给'\0'留个空间，MultiByteToWideChar不会给'\0'空间
    wchar_t* wszString = new wchar_t[wcsLen + 1];
    //转换
    ::MultiByteToWideChar(CP_ACP, NULL, szAnsi, strlen(szAnsi), wszString, wcsLen);
    //最后加上'\0'
    wszString[wcsLen] = '\0';
    //unicode版的MessageBox API
    ::MessageBoxW(GetSafeHwnd(), wszString, wszString, MB_OK);

    //接下来写入文本
    //写文本文件，头2个字节0xfeff，低位0xff写在前
    CFile cFile;
    cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
    //文件开头
    cFile.SeekToBegin();
    cFile.Write("\xff\xfe", 2);
    //写入内容
    cFile.Write(wszString, wcsLen * sizeof(wchar_t));
    cFile.Flush();
    cFile.Close();
    delete[] wszString;
    wszString =NULL;


    //方法2
    //设置当前地域信息，不设置的话，使用这种方法，中文不会正确显示
    //需要#include<locale.h>
    setlocale(LC_CTYPE, "chs"); 
    wchar_t wcsStr[100];
    //注意下面是大写S，在unicode中，代表后面是ansi字符串
    //swprintf是sprintf的unicode版本
    //格式的前面要加大写L，代表是unicode
    swprintf(wcsStr, L"%S", szAnsi);
    ::MessageBoxW(GetSafeHwnd(), wcsStr, wcsStr, MB_OK);

}

void CConvertDlg::OnBnClickedButtonUnicodeToAnsi()
{
    // unicode to ansi
    wchar_t* wszString = L"abcd1234你我他";
    //预转换，得到所需空间的大小，这次用的函数和上面名字相反
    int ansiLen = ::WideCharToMultiByte(CP_ACP, NULL, wszString, wcslen(wszString), NULL, 0, NULL, NULL);
    //同上，分配空间要给'\0'留个空间
    char* szAnsi = new char[ansiLen + 1];
    //转换
    //unicode版对应的strlen是wcslen
    ::WideCharToMultiByte(CP_ACP, NULL, wszString, wcslen(wszString), szAnsi, ansiLen, NULL, NULL);
    //最后加上'\0'
    szAnsi[ansiLen] = '\0';
    //Ansi版的MessageBox API
    ::MessageBoxA(GetSafeHwnd(), szAnsi, szAnsi, MB_OK);

    //接下来写入文本
    //写文本文件，ANSI文件没有BOM
    CFile cFile;
    cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
    //文件开头
    cFile.SeekToBegin();
    //写入内容
    cFile.Write(szAnsi, ansiLen * sizeof(char));
    cFile.Flush();
    cFile.Close();
    delete[] szAnsi;
    szAnsi =NULL;


    //方法2
    //和上面一样有另一种方法
    setlocale(LC_CTYPE, "chs"); 
    char szStr[100];
    //注意下面是大写，在ansi中，代表后面是unicode字符串
    //sprintf
    sprintf(szStr, "%S", wszString);
    ::MessageBoxA(GetSafeHwnd(), szStr, szStr, MB_OK);
}

void CConvertDlg::OnBnClickedButtonUnicodeToU8()
{
    // unicode to UTF8
    wchar_t* wszString = L"abcd1234你我他";
    //预转换，得到所需空间的大小，这次用的函数和上面名字相反
    int u8Len = ::WideCharToMultiByte(CP_UTF8, NULL, wszString, wcslen(wszString), NULL, 0, NULL, NULL);
    //同上，分配空间要给'\0'留个空间
    //UTF8虽然是Unicode的压缩形式，但也是多字节字符串，所以可以以char的形式保存
    char* szU8 = new char[u8Len + 1];
    //转换
    //unicode版对应的strlen是wcslen
    ::WideCharToMultiByte(CP_UTF8, NULL, wszString, wcslen(wszString), szU8, u8Len, NULL, NULL);
    //最后加上'\0'
    szU8[u8Len] = '\0';
    //MessageBox不支持UTF8,所以只能写文件

    //接下来写入文本
    //写文本文件，UTF8的BOM是0xbfbbef
    CFile cFile;
    cFile.Open(_T("1.txt"), CFile::modeWrite | CFile::modeCreate);
    //文件开头
    cFile.SeekToBegin();
    //写BOM，同样低位写在前
    cFile.Write("\xef\xbb\xbf", 3);
    //写入内容
    cFile.Write(szU8, u8Len * sizeof(char));
    cFile.Flush();
    cFile.Close();
    delete[] szU8;
    szU8 =NULL;

}

void CConvertDlg::OnBnClickedButtonU8ToUnicode()
{
    //UTF8 to Unicode
    //由于中文直接复制过来会成乱码，编译器有时会报错，故采用16进制形式
    char* szU8 = "abcd1234\xe4\xbd\xa0\xe6\x88\x91\xe4\xbb\x96\x00";
    //预转换，得到所需空间的大小
    int wcsLen = ::MultiByteToWideChar(CP_UTF8, NULL, szU8, strlen(szU8), NULL, 0);
    //分配空间要给'\0'留个空间，MultiByteToWideChar不会给'\0'空间
    wchar_t* wszString = new wchar_t[wcsLen + 1];
    //转换
    ::MultiByteToWideChar(CP_UTF8, NULL, szU8, strlen(szU8), wszString, wcsLen);
    //最后加上'\0'
    wszString[wcsLen] = '\0';
    //unicode版的MessageBox API
    ::MessageBoxW(GetSafeHwnd(), wszString, wszString, MB_OK);

    //写文本同ansi to unicode
}