Asp.Net 应用百万级优化方法-数据库优化

Asp.Net 网站优化教程系列之数据库教程优化措施 使用主从库（全）
 以豆瓣读书书的详细页为假定场景，你可以点击这里看下页面的结构（我不是豆瓣的技术，在这里只是拿这个页面举例）
我们来分析呈现这个页面需要的数据和这些数据的实效性要求
1） 书的详细信息 时效性要求：要求及时
2） 豆瓣成员的常用标签 实效性：不需要很及时
3） 喜欢读这本书的人也喜欢读的书 属于分析数据，不需要很及时
4） 最新书评 要求及时
5） 读这本书的几个用户 及时性不高
6） 喜欢这本书的人常去的小组 属于分析数据不需要很及时
从上面的分析可以看出只有1），4）两项数据需要从主库读，而2），3），5），6）为非及时数据从从库读取即可。当然我们可以对这些实效性不高的数据做缓存处理。

2. 以论坛帖子列表页面为假定场景，玩论坛的人都喜欢顶贴，把自己的帖子顶到第一页让更多的人关注，而对于50页之后的帖子则反读的人很少；我们可以根据这个业务逻辑特征来决定在用户访问前50页帖子列表数据时从主库读，而当用户访问超过50页之后的数据时则从从库进行查询。

3. 以订单为例，通常超过三个月的订单就不会再有变化了，假定我们把订单号设计为日期格式时，根据订单号去查询订单时就可以根据订单号来决定该访问主库还是从库。

举了几个适用的场景，我们以第三个场景为例，写一段简单的示意代码看下

复制代码 代码如下:
//orderNo 的格式为 20100528120105000001 即yyyyMMddHHmmss + 序号
public OrderInfo GetOrder(string orderNo) {
string connString = ConnStringGetter.GetForOrder(orderNo);
using (SqlConnection conn = new SqlConnection(connString))
{
...
}
} 

public class ConnStringGetter
{
public static string GetForOrder(string orderNo) {
int year = int.Parse(orderNo.Substring(0,4));
int money = int.Parse(orderNo.Substring(4,2));
int date = int.Parse(orderNo.Substring(6,2));
DateTime orderTime = new DateTime(year, money, date);

TimeSpan ts = DateTime.Now - orderTime;
//根据订单的时间决定使用主库还是从库
if (ts.TotalDays > 30) return ConfigurationManager.ConnectionStrings["CONN_Slave"].ConnectionString;
return ConfigurationManager.ConnectionStrings["CONN_Master"].ConnectionString;
}
}

Asp.Net 网站优化系列之数据库优化分字诀上 分库
1. 分成多个库，没了外键了以前的inner join操作要跨库吗？

假定场景：博客表有对用户表的外键引用，我们需要在首页显示博客列表，博客列表需要显示用户名和用户id的信息

之前用户表，博客表在一个库里面的时候我们可以通过外键inner join来取得用户的关联信息，现在用户库和博客库被拆成了两个库，我想对跨库做inner join说no；为什么呢，因为这不适合扩展，假如有一天我们的业务量又增长了我们就需要把用户库挪到另外一台机器上，这要导致inner join跨服务器了，这显然不是一个好办法，那该怎么办呢？ 我有两种方案，大家评判好坏：

1）做违反范式的设计，将用户的不变信息用户名和用户id一起存在博客表中，让用户名冗余吧，这样做可以保证取博客数据连带用户名时是非常高效率的

2）我们不再从数据库中取用户名的信息，改从缓存中取，我们可以在缓存中形成一个最近活跃的用户数据池，当我们需要用户名时从这个缓存区中去取。

目前在我的应用中用的是第一种方案，第二种更有伸缩性，第一种存冗余数据只能存用户名，有时候只存用户名就够了，有时候可能会出现不够的问题。

2. 如果用到了根据外键做的级联删除，那这是一个噩梦

对付这个问题，我的方案是修改程序，如果需要级联删除，在程序逻辑中完成，不要在数据库做级联删除了，级联删除是一种隐含在数据库中的逻辑，是一种不好的设计方案。

3. 触发器也可能带来和外键做级联删除同样的麻烦，同样的也是修改程序逻辑，代替这种数据库级别的隐含逻辑。

也许你会说分库之后一定会带来性能的提高吗？这个问题得具体分析，这要看你的服务器性能如何，如果分库之后数据库的cpu，io，内存的压力依然很大；那么您可以将分库之后的其中某一个库迁移到另外一台服务器上，让两台服务器分摊数据访问的压力，肯定会提升性能的。

纵向分表
纵向分表是指将一个有20列的表根据列拆分成两个表一个表10列一个表11列，这样单个表的容量就会减少很多，可以提高查询的性能，并在一定程度上减少锁行，锁表带来的性能损耗。

纵向分表的原则是什么呢，应该怎样拆分呢？答案是根据业务逻辑的需要来拆分，对于一张表如果业务上分两次访问某一张表其中一部分数据，那么就可以根据每次访问列的不同来做拆分; 另外还可以根据列更新的频率来拆分，例如某些列每天要更新3次，有些列从创建开始基本上很少更新。

举例：
假定场景，我有一张用户表，这张表包含列：
ID, UserName, Password, RealName, Gender, Email, IsEmailValid, Birthday, Country, City, Address, Mobile, Phone, ZipCode, Hometown, OfficePhone, Company, Position, Industry, LatestLoginTime, LatestLoginIP, LoginTimes,OnlineMinutes

假定现在我们的登录出现了性能问题，用户登录经常出现数据库超时的现象。我们打算用拆表的方法解决这个问题。先看下涉及到登录的字段有：UserName,Password,LatestLoginTime,LatestLoginIP,LoginTimes；那么我们就可以以此为依据将原表拆分为：UserLogin和UserBase 两个表，后者包含除了登录信息的其他列信息；两张表都要包含主键ID。

2. 横向分区
横向分区是将表从行的角度拆分，例如将创建时间在05年之前的数据放在一个分区上，将05年到08年之间的数据放到另一个分区上，以此类推。横向分区所根据的列必须在聚集索引上，通常会根据时间，主键id等进行划分。

横向分区将数据划分为不同的区，在根据分区列条件进行查询时可以缩小查询的范围，从而提高查询的性能；另外如果数据库服务器有多个cpu，则可以通过并行操作获得更好的性能。

到底要根据那个列进行横向的分区和查询有关系，我们在建表的时候需要分析，会根据那个列进行查询。

举例：
1. 订单是一个实效性很强的实体，我们很少查询几年前的订单数据，我们就可以在订单的创建时间列上创建分区函数来做分区。
2. 比如帖子通常情况下只有在首页推荐的最新的帖子被访问次数很多，而几年前的帖子被访问的几率较小，这时候我们可以根据帖子的主键id来做分区，id小于300w的在一个分区上，id在300到600w之间的在一个分区上。