复制：将数据传输到其他服务器上存储，做备份。
镜像：主服务器数据库挂了，另一台自动成为主服务器运行，
日志：可控制的镜像。
集群：主服务器挂了，另一台自动成为主服务器运行，并不仅限于数据库。

明细：引自http://hi.baidu.com/jaimy_jie/blog/item/6e099ed52f42a4d250da4b24.html

一, 数据库复制

SQL Server 2008数据库复制是通过发布/订阅的机制进行多台服务器之间的数据同步，我们把它用于数据库的同步备份。这里的同步备份指的是备份服务器与主服务器进行 实时数据同步，正常情况下只使用主数据库服务器，备份服务器只在主服务器出现故障时投入使用。它是一种优于文件备份的数据库备份解决方案。

SQL Server的复制分为种：

1. 快照发布:

发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。每隔一段时间将订阅数据库中的相应表中的数据全部删除，然后将自己相应表中的全部插到订阅数据库中

使用快照复制本身是最合适的：
1）很少更改数据。
2）在一段时间内允许具有相对发布服务器已过时的数据副本。
3）复制少量数据。
4）在短期内出现大量更改。

在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。 对于给定的某些类型的数据，更频繁的快照可能也比较适合。 例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。

发布服务器上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。 但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。 评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。

2. 事务发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。

事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。

以下各种情况下适合采用事务复制：
1). 希望发生增量更改时将其传播到订阅服务器。
2). 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
3). 应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
4).发布服务器有大量的插入、更新和删除活动。
5).发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。

默认情况下，事务发布的订阅服务器应视为只读，因为更改将不会传播回发布服务器。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项

3. 具有可更新订阅的事务发布:

在 SQL Server 订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。来自订阅服务器的事务被应用于发布服务器。

4. 合并发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布。

与事务复制相同，合并复制通常也是从发布数据库对象和数据的快照开始， 并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。 订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。

合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：
1). 多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
2). 订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
3). 每个订阅服务器都需要不同的数据分区。
4). 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
5). 应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。

合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。 因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法

复制的缺点： 表有主键，而且表结构日后不能更改，如果架构稳定也是不错的，如果有很多张表那就比较麻烦了

复制方法及过程：

http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html

http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html

http://dufei.blog.51cto.com/382644/84645

http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html

二，数据库镜像：

数据库镜像：

优点是系统能自动发现主服务器故障，并且自动切换至镜像服务器。

缺点是配置复杂，镜像数据库中的数据不可见（在SQL Server Management Studio中，只能看到镜像数据库处于镜像状态，无法进行任何数据库操作，最简单的查询也不行。想眼见为实，看看镜像数据库中的数据是否正确都不行。只 有将镜像数据库切换主数据库才可见）

相对于日志传送，数据库镜像显然更高一级。在最简单的形式下，它其实与日志传送的工作原理相似，但是生产服务器发送事务到镜像服务器的频率要高得多，这意味着更新速度也要快很多。

　　对于数据库镜像来说，故障转移功能也是需要手动完成。但是你可以添加第三个SQL Server，称为witness。Witness可以作为一个普通的SQL Server，但是一直留意着其它两个镜像服务器。当主镜像发生故障，witness可以让第二个镜像接管操作，类似一种自动的故障转移。

　　在故障转移时，任何进行中的客户端事务都将重新启动，而由于在这一过程中仍然存在着延迟，镜像服务器也不能保证百分之百不丢失数据。

三，数据库日志传输：

作为高可用性的最低级形式，日志传送(log shipping)本质上是SQL Server复制功能的一种延伸

允许解决方案提供商创建多个数据库副本。日志传输能够将次数据库日志副本同步发送到SQL Server实例上。然后这些日志会在次服务器上重放，从而保持数据库副本是最新的。

　　有一些解决方案提供商使用日志传输作为克服数据库镜像缺点的方法。数据库镜像是很好的技术，但是它只允许我们实现一个数据库副本。镜像可以接近实时的方式进行，所以数据库修改可以快速地写到次数据库上。如果客户数据库损坏或数据库记录意外删除，那么这可能会造成问题。

　　日志传输有两个主要的优点。首先，解决方案提供商能够实现一种延迟，这样日志就不会即时重放。这是很重要的，因为如果主(或镜像)数据库出现问题，日志可以在重放之前拦截，因此可以防止问题扩散。

　　日志传输第二个主要的优点是它支持实现多个数据库副本。有一些单位使用日志传输作为在备份数据中心维护数据库副本的方法，这能够防止主数据中心出现问题时发生数据丢失。

　　 虽然日志传输通过是作为数据库镜像的补充措施，但是它是一种独立的技术，它可以不依赖于镜像技术而独立使用。

http://www.searchdatabase.com.cn/showcontent_11708.htm

四，故障转移集群

集群技术是微软可用性的最高级形式，它需要你设置一个Windows集群。

　　在集群中并不会涉及传输以及镜像，取而代之，两台或更多的电脑将会彼此连接在一个共享的外部存储器中，通常是存储区域网络(SAN)。数据库文件就存放在这个共享存储器上，同样设置的SQL Server实例都运行在集群节点上。

　　集群中的所有节点中，实际上只有一个节点是一直处在活动状态的，如果这个节点发生故障，其它的节点将启动相应的SQL Server实例，并连接共享存储器的数据文件。而整个故障转移过程往往只有几秒钟时间，对于任何给定的SQL Server实例，Windows集群技术都可以确保客户端始终注视活动的节点。

　　集群技术非常复杂，但它是实现高可用的最高效技术。与前面介绍的两个功能相比，集群依赖于一个单一的数据库文件集。如果这些文件损坏了，故障转移也不能起作用了，因为故障转移的实例同损坏的文件是一样的。而使用镜像与日志传送，你可以对文件进行实时拷贝，因此不必担心文件损坏的问题。SQL Server中，文件遭到损坏的情况很少发生，因此我认为集群应该还是一个不错的选择。

缺点的。其中一个重要的问题是故障恢复的实现是非常昂贵的。Microsoft只在那些通过Windows Server认证的硬件上才支持故障恢复。 另一个问题是它要求使用共享存储

go N :执行批语句N次

Create Table #Temp(SerialNo int identity Primary key, Product varchar(500))
go
 
Declare @Product varchar(500)
SET @Product='Mouse'
insert into #Temp(Product)
select @Product

GO 20

select * from #Temp
drop Table #Temp

磁盘负责三方面，一个将数据写入到日志文件ldf中，然后在check point后写入到mdf, 接着就是大量的读操作。
先写入ldf,是因为sql server的预写日志机制引起的，此机制保证了数据在写入到mdf中前，一定会在ldf中保留一份，这样以后恢复等操作都可进行，故可以说，影响写性能的主要是写入到ldf中的操作。磁盘一边负责随机取数据，一边负责写入数据，磁头转来变去，性能低下，而将ldf文件放在不同的磁盘中，就独立了写操作。
注意：磁盘应是物理上的。

Other logical drive will not benefit because ultimately, it’s the same drive controller and the same physical disc. Hence, if the heads are busy doing random reads for a logical drive D, they won’t be able to perform serial writes on logical drive E on the same physical drive.

Hence, the log should be given the priviledge of it’s own separate physical drive.
引自：
Performance Best practice – Transaction log must on a different drive. But WHY?
Write-Ahead Transaction Log

当 SET NOCOUNT 为 ON 时，不返回计数（表示受 Transact-SQL 语句影响的行数）。当 SET NOCOUNT 为 OFF 时，返回计数。

即使当 SET NOCOUNT 为 ON 时，也更新 @@ROWCOUNT 函数。

当 SET NOCOUNT 为 ON 时，将不向客户端发送存储过程中每个语句的 DONE_IN_PROC 消息。使用由 SQL Server 2005 提供的实用工具执行查询时，其结果会防止在 Transact-SQL 语句（例如 SELECT、INSERT、UPDATE 和 DELETE）的末尾显示 nn rows affected。

如果存储过程中包含的一些语句并不返回许多实际数据，则该设置由于大量减少了网络流量，因此可显著提高性能。

SET NOCOUNT 设置是在执行或运行时设置，而不是在分析时设置。

1, INFORMATION_SCHEMA.COLUMNS :存储列定义，包含列类型，长度等信息。
2，INFORMATION_SCHEMA.PARAMETERS：存储过程参数信息。
如：查询行长度：
select
c.table_name,
count(*) columns,
sum(
case data_type
when 'binary' then character_maximum_length
when 'varbinary' then character_maximum_length
when 'char' then character_maximum_length
when 'varchar' then character_maximum_length
when 'nchar' then character_maximum_length
when 'nvarchar' then character_maximum_length
when 'bigint' then 8
when 'int' then 4
when 'uniqueidentifier' then 16
when 'datetime' then 8
when 'bit' then 1
when 'image' then 16
when 'text' then 16
when 'ntext' then 16
end) as avgLen
 from INFORMATION_SCHEMA.COLUMNS c join INFORMATION_SCHEMA.Tables t
ON c.Table_Schema=t.Table_Schema AND c.Table_Name=t.Table_Name
WHERE t.TABLE_TYPE='BASE TABLE' AND c.TABLE_NAME NOT IN('dtproperties','sysdiagrams')
--AND table_name like '%log'
group by c.table_name
order by avgLen desc
go

聚集索引叶级别除了保持键值外，还包含所有数据
非聚集索引叶级别只有需要的键值及书签，以“文件号：页号：槽号”的格式定位
查看索引存储：
–打开3604，信息发送到控制台
DBCC TRACEON(3604)
–查看表索引对应的页数明细
DBCC IND (‘brm_lvjian_new’, ‘frmuser’, -1);
–查看页上的数据信息
DBCC PAGE (brm_lvjian_new, 1, 586958, 1);
在Memory Dump下存储着信息。

不过非聚集索引并不一定比聚集索引快，但where条件，select字段都是复合索引字段时，因索引
空间较小，比件聚集索引查找快一些。
如：在frmUser表中DepartmentID上建立非聚集索引
执行：
SELECT departmentid
FROM frmuser
WHERE DepartmentId = 4

SELECT *
FROM frmuser
WHERE DepartmentId = 4

发现前者通过索引查找一步到位，而后者在索引查找后，因还要取其它值，故还要根据索引页键值中的引用，去数据页取值
这提示：SELECT中的字段少一些速度会更快，一是若字段在一索引内，就避免了去数据页的检索，二是避免了大量数据的I/O操作。
复合索引与对字段分别建索引的区别：
1，复合索引整体空间比分别建索引要小。
2，若查询语句对索引内字段查询，复合索引直接得到位置，而分别建索引需要分别查出再连接
并且当SELECT字段也在索引内时，复合索引会直接得出，而分另建索引则需要去数据页重新取。

SELECT objectpropertyex (OBJECT_ID(‘VR_bswGoods’), ‘IsView’)
IsSystemTable
IsUserTable
IsView
IsTable
IsTableFunction
IsTrigger

引用：http://technet.microsoft.com/zh-cn/library/cc966540(en-us).aspx
Sql Server速度变慢问题主要由三个方面引起，可从这三个方面入手分析问题
  1，资源瓶颈：CPU、I/O、内存等。
  2，临时表瓶颈：tempdb各个数据库共用，资源紧张时会引起性能降低。
  3，用户比较耗时的sql查询。

一，CPU瓶颈分析。瓶颈症状：打开perfmon, 监视 processor:% Processor Time若长期>80%，或者任务管理器，说明可能是CPU原因。
1，分析是否是查询语句引起
 这里涉及一个动态视图：sys.dm_exec_query_stats，返回每条查询语句运行的时间
关键栏位有：
 1）sql_handle:表示包含查询的批查询或存储过程的标记,若sql_handle相同，代表查询在同个批处理或同一个存储过程内。可将此值传入    sys.dm_exec_sql_text中获取查询语句。同个存储过程或批处理语句的sql_handle相同，如何分辨是哪个查询语句得到了执行，
可用statement_start_offset、statement_end_offset来查出此查询语句的真容。
2）statement_start_offset：查询在其批查询或持久化对象文本中的开始位置
3）statement_end_offset：查询在其批查询或持久化对象文本中的结束位置
4）execution_count： 计划自上次编译以来所执行的次数。
5）total_worker_time：此计划自编译以来执行所用的 CPU 时间总量（以微秒为单位报告，但仅精确到毫秒）。
6）last_execution_time：上次开始执行计划的时间。
故分析耗CPU语句方法可得出：

--若返回的dbname,objectname为空，代表是动态sql语句，不是存储过程
SELECT 
    dbname,ObjectName,Sql,
    SUM([总消耗CPU 时间(ms)]) [总消耗CPU 时间(ms)],
    SUM([运行次数])[运行次数],[查询语句],[所在存储过程],
    SUM([平均消耗CPU 时间(ms)])[平均消耗CPU 时间(ms)]    
    FROM (
    SELECT TOP (50)
        qs.total_worker_time/qs.execution_count/1000. as [平均消耗CPU 时间(ms)],
        total_worker_time/1000 AS [总消耗CPU 时间(ms)],execution_count [运行次数],
       
        dbo.SQLSig(SUBSTRING(qt.text,qs.statement_start_offset/2+1, --利用sqlsig函数进行参数化，以屏蔽传来的参数，使之标准化
            (case when qs.statement_end_offset = -1
            then DATALENGTH(qt.text)
            else qs.statement_end_offset end -qs.statement_start_offset)/2 + 1),4000)
        as [查询语句], qt.text [所在存储过程],
        qt.dbid, dbname=db_name(qt.dbid),
        qt.objectid,object_name(qt.objectid,qt.dbid) ObjectName
    FROM sys.dm_exec_query_stats qs
    cross apply sys.dm_exec_sql_text(qs.sql_handle) as qt
    ORDER BY [平均消耗CPU 时间(ms)] DESC
    )M
    GROUP BY [查询语句],[所在存储过程],dbid, dbname,objectid,ObjectName
    ORDER BY [平均消耗CPU 时间(ms)] DESC

注：测试sys.dm_exec_query_stats 时可先清除缓存DBCC FREEPROCCACHE 再执行查询语句分析。

2，分析是否是重新编译引起，重新编译比较费时。
1）perfmon:

    SQL Server: SQL Statistics: Batch Requests/sec :每秒钟接收的请求数

    SQL Server: SQL Statistics: SQL Compilations/sec：每秒钟的编译数

    SQL Server: SQL Statistics: SQL Recompilations/sec：每秒钟的重新编译数

2）profile:SP:Recompile / SQL:StmtRecompile.
3）sys.dm_exec_query_stats 有一个栏位plan_generation_num，计划编译次数，可用此来分析最常编译的计划。
select top 25
    plan_generation_num,
    SUBSTRING(qt.text,qs.statement_start_offset/2+1,
        (case when qs.statement_end_offset = -1
        then DATALENGTH(qt.text)
        else qs.statement_end_offset end -qs.statement_start_offset)/2 + 1)
        as stmt_executing,
    qt.text,
    execution_count,
    sql_handle,
    dbid,
    db_name(dbid) DBName,
    objectid,
    object_name(objectid,dbid) ObjectName
from sys.dm_exec_query_stats as qs
    Cross apply sys.dm_exec_sql_text(sql_handle) qt
where plan_generation_num >1
--AND qs.last_execution_time >='2011-08-28 10:00' 限定时间
order by plan_generation_num desc



二，内存瓶颈分析。瓶颈症状：打开perfmon, 监视 Paging File: %Usage长期>80%。Paging File:Usage: 分页空间使用百分率

三，I/O瓶颈分析：症状：计数器PhysicalDisk:%Disk Time >80% , Avg.Disk Queue Length:>2
1，%Disk Time :所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
Avg. Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
不过，若出现上述情况，也可以是内存不足引起。

2，sys.dm_exec_query_stats 有栏位total_logical_writes：此计划自编译后在执行期间所执行的逻辑写入总次数。total_logical_reads：此计划自编译后在执行期间所执行的逻辑写入总次数。
故查询最耗I/O的语句为：

select top 50
(total_logical_reads/execution_count) as [平均逻辑读取次数],
(total_logical_writes/execution_count) as [平均逻辑写入次数],
(total_physical_reads/execution_count) as [平均对象读取次数],
 Execution_count 运行次数,
substring(qt.text,r.statement_start_offset/2+1,
(case when r.statement_end_offset = -1
then datalength(qt.text)
else r.statement_end_offset end - r.statement_start_offset)/2+1) [运行语法]
from sys.dm_exec_query_stats  as r
    cross apply sys.dm_exec_sql_text(r.sql_handle) as qt
--WHERE r.last_execution_time >='2011-08-28 10:00' 限定时间
order by
 (total_logical_reads + total_logical_writes) Desc

四，tempdb瓶颈。空间资源耗尽引起。
查询：
Select
    SUM (user_object_reserved_page_count)*8 as user_objects_kb,
    SUM (internal_object_reserved_page_count)*8 as internal_objects_kb,
    SUM (version_store_reserved_page_count)*8  as version_store_kb,
    SUM (unallocated_extent_page_count)*8 as freespace_kb
From sys.dm_db_file_space_usage
Where database_id = 2
其中：freespace_kb  要足够大才可。

1，Query Notification:当用户访问的数据改变时，会主动通知前台程序，避免了以往的轮询机制。
2，Event Notification:在用户执行DDL或DML语言后，需要立刻处理的商业逻辑可以通过触发器来完成，但由于触发器执行时会与上述语句绑在一个事务中，因此会拖慢系统响应时间，利用Event Notification可以借由队列积累需求，在系统不忙碌时执行这些需求。
3，当CPU,内存，I/O，带宽等使用率持续超过80%时，表示此系统已达临界门槛，此后系统整体性能必定急速下滑。
4，用户端硬件差也有可能拖慢整个系统，原因：当用户要了一大堆数据，但它没有能力立刻处理完这些服务器源源不断传来的网络包，因此Sql Server对该用户的网络输出缓存区也就塞满了数据，此时并不影响其他用户，但当缓存区满时，扫描数据的工作也将暂停，这时扫描数据所持有的锁不能释放，导致其它用户可能被锁定。
5，因为磁盘是通过磁性和机械臂的运行来访问数据，因此效率远低于CPU和RAM等通过电子运行的速度。
6，学习资料：http://technet.microsoft.com/en-us/sqlserver/bb331794.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx

尝试在数据库 5 中提取逻辑页 (1:1640) 失败。该逻辑页属于分配单元785421321 ，而非 9854555445。
1，利用DBCC CHECKDB检查一致性

发现
bdOrder的 DBCC 结果。
消息 2575，级别 16，状态 1，第 1 行
索引分配映射(IAM)页 (0:0) (位于对象 ID 1785109450，索引 ID 1，分区 ID 72057594326417408，分配单元 ID 72057594346405888 (类型为 In-row data))的下一个指针指向了 IAM 页 (3:6209)，但扫描过程中检测不到它。
消息 7965，级别 16，状态 2，第 1 行

需要修复
保留一个查询页面，执行如下：
use 需要修复的数据库实体的名称
declare @dbname varchar(255)
set @dbname=’需要修复的数据库的名称’
exec sp_dboption @dbname,’single user’,’true’
dbcc checktable(‘需要修复的数据表的名称’,REPAIR_ALLOW_DATA_LOSS)
dbcc checktable(‘需要修复的数据表的名称’,REPAIR_REBUILD)
exec sp_dboption @databasename, N’single’, N’false’?将目标数据库置为多用户状态
然后执行 SQL Server数据修复命令DBCC CHECKDB(’需要修复的数据库实体的名称’) 检查数据库是否仍旧存在错误。注意：修复后可能会造成部分数据的丢失。

快递范围自动筛选：根据客户地址筛选合适快递。

建表ExpressScope：
ExpressID,SendArea,NoSendArea

快递筛选：要明确地址信息的方可筛选
对于快递范围表数据填充ExpressScope方式：
1，服务区域明确
SendArea为每个确切地址,NoSendArea为空
2,服务区域不明确，不服务区域明确
SendArea为空,NoSendArea为每个确切的地址或关键字如村
3,服务区域不明确，不服务区域不明确
如服务区域：县城城区地域派送 不服务区域：县城外均不操作
此类不能执行自动筛选，范围不入ExpressScope。

筛选方式：
CHARINDEX(SendArea,@Address) >0
AND CHARINDEX(NoSendArea,@Address) =0

1,性能：二者一样。
2，区别：CAST 是ANSI标准，Convert不是。CAST对于转换指定日期格式上不满足，而Convert可以。
3，实现上，在MsSql中CAST由Convert实现，即通过：
SELECT CAST ( o.[object_id] AS int)
FROM sys.objects o
在Compute Scalar的属性中查看：
[Expr1037] = 标量运算符(CONVERT(int,[master].[sys].[sysschobjs].[id] as [o].[id],0))
参考：
http://beyondrelational.com/blogs/nakul/archive/2011/07/18/cast-v-s-convert-is-there-a-difference-as-far-as-sql-server-is-concerned-which-is-better.aspx

在利用SELECT REPLACE(‘密水街办?’,’?’,”)发现得到的结果仍为密水街办?,没用将?去掉。
再用SELECT CHECKSUM(‘?’),CHECKSUM(”) 发现得到的结果都是0，说明二者并没有得到区分.
通过改变编码格式解决: SELECT REPLACE(‘密水街办?’ collate Chinese_PRC_BIN2,’?’,”)
查看mssql支持的编码：select * from ::fn_helpcollations()

详细：
mssql默认中文的编码为:Chinese_PRC_CI_AS即：
Chinese-PRC, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive
unicode字符集Chinese-PRC 大陆简体字,大小写不敏感，重音敏感，假名类型敏感，全角半角不敏感
_BIN 二进制排序
_CI(CS) 是否区分大小写，CI不区分，CS区分
_AI(AS) 是否区分重音，AI不区分，AS区分　　　
_KI(KS) 是否区分假名类型,KI不区分，KS区分　
_WI(WS) 是否区分宽度 WI不区分，WS区分

假名类型:平假名是日语中表音符号的一种
重音:英文单词中的重音,如 ，’a’不等同于’á’。
用得最多的是大小写是否区分，全角是否区分，默认都是不区分

可看到默认全角半角，大小写不区分，若想区分，采用编码转换
IF (‘@’ = ‘＠’ collate Chinese_PRC_CI_AS_WS)
PRINT ‘y’
ELSE PRINT ‘n’

系统存储过程sp_MSforeachtable和sp_MSforeachdb,是微软提供的两个不公开的存储过程,从mssql6.5开始。存放在SQL Server的MASTER数据库中。可以用来对某个数据库的所有表或某个SQL服务器上的所有数据库进行管理
参数说明:

   @command1 nvarchar（2000）,                      --第一条运行的SQL指令
   @replacechar nchar（1） = N'?',                      --指定的占位符号，默认为?
   @command2 nvarchar（2000）= null,            --第二条运行的SQL指令
   @command3 nvarchar（2000）= null,            --第三条运行的SQL指令
   @whereand nvarchar（2000）= null,               --可选条件来选择表
   @precommand nvarchar（2000）= null,        --执行指令前的操作(类似控件的触发前的操作)
   @postcommand nvarchar（2000）= null       --执行指令后的操作(类似控件的触发后的操作)

   以后为sp_MSforeachtable的参数，sp_MSforeachdb不包括参数@whereand

如：查询当前数据库中所有以bd开头的表的容量

查询一条用:sp_spaceused

多条用：
CREATE TABLE #TableSpaceUsed(
TableName SYSNAME,
Rows INT,
Reserved VARCHAR(20),
DataSize VARCHAR(20),
IndexSize VARCHAR(20),
UnUsed VARCHAR(20))

EXEC sp_MSForEachTable
@command1=N'insert into #TableSpaceUsed exec sp_spaceused ''?''',@whereand='and o.name like ''%'''

SELECT * FROM #TableSpaceUsed
ORDER BY CONVERT(INT,REPLACE(Reserved,' KB','')) DESC
--更新PUBS数据库中已t开头的所有表的统计: EXEC sp_MSforeachtable @whereand="and name like 't%'", @replacechar='*', @precommand="print 'Updating Statistics.....' print ''", @command1="print '*' update statistics * ", @postcommand= "print''print 'Complete Update Statistics!'" --遍历数据库文件

--遍历数据库文件
CREATE TABLE #DataBaseFiles(
DB SYSNAME,
LogicName SYSNAME,
physical_name nvarchar(260),
FILENAME nvarchar(260),
FileSize DECIMAL(18,1)
)

--要用user ? 否则返回的结果仍是当前库的数据
EXEC sp_MSforeachdb 'USE ?  insert into #DataBaseFiles SELECT ''?'',name, substring(filename,len(filename) - charindex(''\'', reverse(filename))+2,charindex(''\'', reverse(filename))),filename, CONVERT(DECIMAL(18,1),(size*8.0/(1024*1024))) AS Size_GB FROM sys.sysfiles '

SELECT *
FROM #DataBaseFiles

Run same command on all SQL Server databases without cursors

1, tableA JOIN tableB ON …
对于tableA与tableB满足ON条件的抓出。
过程模拟：对于tableA的每一行记录，遍历tableB的每行记录，若tableA与tableB的当前记录都满足ON条件，那么将tableA与tableB的当前记录取出，遍历完之后，若有LEFT,JOIN之类，则在取出的结果表中再加上没有满足条件的tableA外行即可。
即：LEFT JOIN 与 JOIN的区别在于：在对ON条件执行过滤后，是否再增加外行。
2,理解
1)
tableA JOIN tableB ON 1=1 :对于tableA与tableB的每一条记录，都满足1=1故相当于求tableA与tableB的笛卡儿积。
tableA LEFT JOIN tableB ON 1=1: 对于tableA与tableB的每一条记录，都满足1=1,抓取出。然后将不满足条件的tableA的行取出加上，但tableA所有记录都满足条件，故增加的外行为0 即此时：LEFT JOIN = JOIN
2) tableA JOIN tableB ON tableA.id = 1 :将tableA ID为1的与tableB所有记录连接。
tableA LEFT JOIN tableB ON tableA.id = 1 :将tableA ID为1的与tableB所有记录连接，然后再将tableA ID不为1的加上。

3) on 后的条件为>=或<=时，可用来求解阶梯问题。

/*1，判断集合A是否属于集合B
* 2，判断集合A是否等于集合B
若集合wa属于集合wb,那么wa的任意一个元素都会在集合wb中存在,并且wb的元素数量要>=wa的元素数量*/

WITH wa AS (
SELECT 'a1' product
UNION ALL
SELECT 'b2'
),
wb AS (
SELECT 'Ta' TYPE,'a1' product
UNION ALL
SELECT 'Ta' ,'b2'
UNION ALL
SELECT 'Tb' ,'a1'
UNION ALL
SELECT 'Tb' ,'b2'
UNION ALL
SELECT 'Tb' ,'c3'
UNION ALL
SELECT 'Tc' ,'a1'
UNION ALL
SELECT 'Td' ,'b2'     
UNION ALL
SELECT 'Td' ,'c3'  
UNION ALL
SELECT 'Te' ,'a1'
UNION ALL
SELECT 'Te' ,'a1'
UNION ALL
SELECT 'Tf' ,'a1'
UNION ALL
SELECT 'Tf' ,'d1'
)

/*若集合wa属于集合wb,那么wa的任意一个元素都会在集合wb中存在,并且wb的元素数量要>=wa的元素数量*/

/* 1,集合属于判断*/
SELECT b.type
FROM wb b(NOLOCK)
JOIN wa a(NOLOCK) ON b.product = a.product  --取出至少包含wa一个元素的所有集合
GROUP BY b.type
HAVING COUNT(DISTINCT b.product) = (SELECT COUNT(1) FROM wa) --保证wa的任意一个元素都会在集合wb中存在                                                         --
ORDER BY b.type

/*2,集合等于判断
SELECT b.type
FROM wb b(NOLOCK)
JOIN wa a(NOLOCK) ON b.product = a.product  --取出至少包含wa一个元素的所有集合
WHERE  ( SELECT COUNT(1) FROM wb WHERE wb.type = b.type  ) = ( SELECT COUNT(1) FROM wa) --集合数量要相等
GROUP BY b.type
HAVING COUNT(DISTINCT b.product) = (SELECT COUNT(1) FROM wa) --保证wa的任意一个元素都会在集合wb中存在                                                               --
ORDER BY b.type


*/

参考：http://technet.microsoft.com/zh-cn/library/ms144259(SQL.90).aspx
运行：start /wait setup.exe /qb /settings setup.ini （注：setup.exe最好是SQL Server x86\Servers下的）
start /wait :dos命令，启动应用程序并等待它结束。
setup.ini可参考\SQL Server x86\Servers下的template.ini文件
注：其中的/qb表示可看见安装画面，若改为/qn则完全在后台运行安装
setup.ini配置:
[Options]
USERNAME=user
COMPANYNAME=lvshou
PIDKEY=B4H74BJX3P37RX2J9TTBH9RMJ
INSTALLSQLDIR=”C:\Program Files\Microsoft SQL Server\”
INSTALLOLAPDATADIR=”C:\Program Files\Microsoft SQL Server\MSSQL\OLAP\Data”
ADDLOCAL=All
INSTANCENAME=MSSQLSERVER
SECURITYMODE=SQL
SAPWD=LifeIsGood
SQLACCOUNT=NT AUTHORITY\SYSTEM
AGTACCOUNT=NT AUTHORITY\SYSTEM
SQLBROWSERACCOUNT=NT AUTHORITY\SYSTEM
ASACCOUNT=NT AUTHORITY\SYSTEM
RSACCOUNT=NT AUTHORITY\SYSTEM
SQLBROWSERAUTOSTART=1
SQLAUTOSTART=1
AGTAUTOSTART=1

注：INSTALLOLAPDATADIR，数据库文件（如.mdf和.ldf）的默认存放目录
ASACCOUNT:Analysis Services
RSACCOUNT:Reprot Services
SQLBROWSERAUTOSTART=1 1为自动启动，0为手动启动。
SQLAUTOSTART=1
AGTAUTOSTART=1
SECURITYMODE=SQL ：身份验证模式，当为sql时表示混合验证，若未指定，则是windows验证

SQLServer2005SP3-KB955706-x86-CHS.exe /quiet /allinstances

对于结果集包含NULL的情况：
1，当用IN时，若在结果集中存在，则返回TRUE,若在结果集中不存在，因结果集中有NULL，则返回UNKNOWN, UNKNOWN类似于False,故用IN可返回TRUE或False,同用Exists一样。
2，用IN时，返回TRUE或UNKNOWN，那么用NOT IN时，就返回NOT TRUE 或NOT UNKNOWN 即：False或NOT UNKNOWN,因NOT UNKNOWN = UNKNOWN,类似于False,故对于结果集包含NULL时，会一直返回False!即一直没有结果。
故：当当用NOT IN时，若不能保证结果集一定没有NULL，则最好用NOT EXISTS

总则：观察规律，将规律固定下来。
连续范围：1，2，3，4，7，8，11，12，15
连续范围为：1,2,3,4 | 7,8 |11,12
特点：若按从小到大的顺序给行号，则在连续范围中的与行号相减，应为一固定数值
如：
字段值 行号 相减值
1 1 0
2 2 0
3 3 0
4 4 0
7 5 2
8 6 2
11 7 4
12 8 4
15 9 6
相减值相对的是处于连续范围内，按此值分组，求最小字段值、最大字段值即是连续范围

如： 求6月份连续业绩大于100万的日期范围
第一：求日期相减值； 第二：分组求范围

/*6月份业绩超过100万的日期范围*/
WITH DayAchievement AS(
SELECT CONVERT(VARCHAR(10),bo.OrderDate,120) OrderDate,SUM(amount) OrderSum
FROM bdOrder bo(NOLOCK)
JOIN mdOrderStatus mos(NOLOCK) ON bo.OrderStatus = mos.StatusCode AND mos.IsAchievement = 1
WHERE bo.OrderDate >=’2011-06-01′
GROUP BY CONVERT(VARCHAR(10),bo.OrderDate,120)
)

SELECT MIN(OrderDate),MAX(OrderDate),
DATEDIFF(dd,MIN(OrderDate),MAX(OrderDate))+1,
SUM(OrderSum)
FROM (
SELECT a.OrderDate,a.OrderSum,DATEADD(dd,-1 * ROW_NUMBER() OVER ( ORDER BY a.OrderDate)+1,a.OrderDate) gy
FROM DayAchievement a
WHERE OrderSum >= 1000000
)m
GROUP BY gy

注：DATEADD(dd,-1 * ROW_NUMBER() OVER ( ORDER BY a.OrderDate)+1,a.OrderDate) gy 即是相减值(规律值)

中值：若总数为奇数，则中数为中间那个，若为偶数，则为中间两个平均 WITH RN AS(
SELECT CONVERT(VARCHAR(10),a.OrderDate,120) OrderDate,amount,
ROW_NUMBER () OVER ( PARTITION BY CONVERT(VARCHAR(10),a.OrderDate,120)  ORDER BY a.Amount,a.id) rx,
ROW_NUMBER () OVER ( PARTITION BY CONVERT(VARCHAR(10),a.OrderDate,120)  ORDER BY a.Amount DESC,a.id DESC  ) rl
FROM bdOrder a(NOLOCK)WHERE a.OrderDate >='2011-05-01' )
注：正序与倒序排，因为Amount值相同的情况，故要加id决定决胜因子。