接上文：会话状态是否适合放在SQL数据库中？

　　如何判定会话状态保存在SQL数据库中?

　　这很容易。你会有一些稀奇古怪的数据库，在简单恢复模式中可能通常称为“aspnetdb”(可能还会带个前缀或者后缀)。

　　会话状态会引起哪些其它问题?

　　那么首先，它会消耗你其它数据库的缓冲池资源。因为会话状态数据库的访问频率非常密集，从数据库中提取的会话数据总是保持在内存中。然而，你会话状态数据库中的数据越多，你的其它数据库上损失的缓冲池空间就越多。由于会话状态工作的方式就是这样的，每次我们在网站上点击一页的时候，至少会调用会话状态数据库一次，这几乎相当于强迫数据库服务器把数据库中的数据保持在缓冲池中。

　　你可以看到的另一个问题是“幻影记录”。Paul Randal在他的博客文章“深度幻影清理”中描述了完美的幻影记录。

　　在同一篇博客文章中，他还谈到关于如何解决该问题的话题，这里我留个悬念，你可以浏览他的博客看到所有内容。

　　另一个问题可以追溯到SQL Server会把一切保持到磁盘上这一事实，随着数据库中信息的不断改变，网站访问量增长，你会需要给会话状态数据库配备更加快速的磁盘才能保持跟得上。当网站访问量进一步增长时，你为了得到更快的磁盘最终会花费越来越多的钱，这一切只是为了保持会话状态的运转，该SQL Server服务器上留给其它应用的资源就更少了。你甚至可能会达到最终需要专门的SQL Server来运行会话状态数据库的地步。

　　另一个问题还是非常古老的锁定与阻塞问题。SQL Server喜欢在进行插入，更新和删除操作时采取页面级别的锁。如此一来，除非磁盘上每个页都只有一行，否则当其他用户会话状态信息被更新时，你的处理就会被阻塞短暂的片刻。你可以通过调整会话数据库的存储过程并强迫行锁来在一定程度上解决这个问题，但是这样你就有了更多的锁(这些锁需要更多的内存)。