本文只是一个入门级别的数据库案例。
希望能通过一些经典案例的分析，大家能共同讨论和分享。
数据库案例(一）简单的用户表。
业务假设：
用户表，10个列，无外键， 200万数据 （如果数据量再大一般就考虑分表了）
以下是假设的操作分布 （仅供参考）
50% 按照用户Id查询
40%按照用户名查询
8%按照Email查询
1.5%修改用户的数据，例如状态，最后登录时间
0.5%添加用户数据
操作特征：一般都只有单条数据的查询
(如果有分析和统计，一般弄一个同步库出来，在那个单独的库上做较大数据量的分析)
(某些操作，例如用户排名，最近用户操作等，一般是用其他的方式实现，而不是直接压在用户表上)
(当然，如果数据量要求不大。。。。其实你做什么都没关系)
软硬件环境：
CPU： I5
内存：4GB
OS：Windows 7 x64 旗舰版
SqlServer 2008R2 企业版
（不是服务器环境，有些配置没有达到最优化）
先创建用户表，插入200万+数据 （Id为聚集索引，而且连续分布，经常删除数据会导致数据不连续降低性能，所以有些时候选择通过状态位假删数据）
CREATE TABLE [dbo].[User](
[Id] [int] IDENTITY(1,1) NOT NULL,
[UserName] [varchar](255) NOT NULL,
[Password] [varchar](255) NOT NULL,
[Email] [varchar](255) NOT NULL,
[Age] [smallint] NULL,
[Gender] [smallint] NULL,
[Signature] [varchar](255) NULL,
[CreatedTime] [date] NOT NULL,
[LastActivityTime] [date] NOT NULL,
[Status] [int] NULL,
[UserNameCode] [binary](16) NULL,
CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]由于只有3个列支持条件查询，而Id列是默认的聚集索引，所以只要新建两个索引，分别在UserName列和Email列 （一般来说所有可能出现在where语句中的列 都应该建立索引）
总所周知，过多的索引会降低修改性能，而该案例中查询远比修改来的多
第一：按照Id查询 （聚集索引，Id连续）
Declare @Stopwatch datetime
declare @number int
Set @Stopwatch=GetDate()
set @number=0
while (@number<1000)
begin
select * from [user] where id=cast(rand()*2000000 as int)
set @number=@number+1
end
Print DateDiff(ms, @Stopwatch, GetDate()); -- 查询1000次 输出结果为 22773 毫秒第二：按照用户名查询 （Email是一样的）
1.无索引，无数据缓存，（查询1次 15秒左右）
DBCC DROPCLEANBUFFERS --这句清除数据的缓存
select * from [user] where username = 'user_'+cast(cast(rand()*2000000 as int) as varchar) --用户名的规则是 user_id 实在不好找其他的高命中率的例子了 勉强用吧
2.无索引 ，有数据缓存 （1000次随机查询，71473毫秒）
Declare @Stopwatch datetime
declare @number int
Set @Stopwatch=GetDate()
set @number=0
while (@number<1000)
begin
select * from [user] where username = 'user_'+cast(cast(rand()*2000000 as int) as varchar)
set @number=@number+1
end
Print DateDiff(ms, @Stopwatch, GetDate());-- 查询1000次 输出结果为71473 毫秒Sql Server，自动给这个列建立了非聚集索引，看以下截图
3.有非聚集索引
在UserName列上建立从立非聚集索引 （整表占用的索引空间从1M增加到80M，表本身空间还是461M，索引大小和列里面数据的大小有直接关系）
以下是执行计划，使用username 查询和使用id查询的对比， 可以看使用username的查询大约比id查询多消耗一倍的资源，实际情况恶劣的多，因为用户名无规律而且长度还高
有的解决方案是为username生成一个HashCode，哈希值经过优化以后可以实现较小体积 （32/64位） 和均匀分布上等优化 (Hash可是号称0(1)的查询时间复杂度。。)
第三种：修改用户状态，密码，最终登录时间和余额等
本例中，只有UserName和Email建立了索引，但是这两个列在逻辑中都考虑为不可修改的
所有可以修改的列都没有建立索引 （主要是修改的成本太高了）
考虑了修改粒度尽可能小，SQL Server 2005版本和以上支持行锁
第四：添加新用户数据
要注意的是添加新数据加的是表锁。。。
第五：混合操作
这东西一靠基本功，例如了解锁类型，锁粒度，隔离级别等概念，这篇文章应该是比较有用处的，http://msdn.microsoft.com/en-us/library/ms190615.aspx
二靠工具模拟和测试，压力测试工具，性能测试工具，SqlServer Profiler
附录：
1.清除缓存
DBCC FREEPROCCACHE - plan cache, removes a specific plan from the plan cache by specifying a plan handle or SQL handle, or removes all cache entries associated with a specified resource pool. -- This can be used for freeing procedure cahce
DBCC DROPCLEANBUFFERS - Removes all clean buffers from the buffer pool. -- Memory cache
2.重建索引
ALTER INDEX ALL ON [User] REBUILD
ALTER INDEX ALL ON [user] REORGANIZE
3.SQL Server数据库生成HashKey的函数
HashBytes('md5', Username)
4.查询目前的lock: sp_lock (sp_who, sp_who2也是很有用的，还有object_name()获取对象名)
