这是读书笔记的最后一篇，说的是数据库，就像之前分享的缓存，不管是读缓存或写缓存，可以减轻数据库的压力，但是缓存随时可能失效或过时，也并不是所有的情况都适用缓存，数据库的优化和扩展也是必须重视的。
运行状况
如何对已运行的数据库进行优化和扩展，以及我们的优化后效果如何，这不是我们想象的，必须在数据的基础上。首先介绍的就是运行状态的监控，书中以mysql为例子，除了自带的命令:
mysql> show status; mysql> show innodb status;
之外，还有mysqlreport工具可用，它把上述命令的输出内容进行处理，以更容易理解的方式呈现给我们。
对于sql server的运行状况，请参考：http://technet.microsoft.com/zh-cn/library/bb838723.aspx
数据库优化
索引
这是所有接触数据库的开发人员最不能忽略的，不管是专业点的DBA或者是刚接触数据库的开发人员，谈及到数据库性能，无不涉及索引，可见索引受关注的程度和使用程度。合理正确的使用，可以极大的提高数据库性能，当然另一个极端也随时出现，没有明确的边界。所有关于使用索引的建议无不是带有另一个极端的可能，如
1，使用索引一定比全表扫描更有效吗？这不是绝对的，如果你要提取的数据占总数据很大的比例，索引查询反而会降低性能。就像你如果要读一本书80%的内容，你会根据目录来一页页读，还是会直接从正文来一次顺序的浏览呢。
2，一个字段出现在查询中基于行的选择、过滤或排序的条件中，那么为该字段建立索引就是有价值的，同样这也不是绝对的。首先我们几乎不可能给出一个描述所有情况的列表，而查询的情况也可能非常的复杂，而同时如果该字段更新会很频繁等等。
其实这更加加剧了我们使用索引的难度，另外索引能提高的只是查询的性能，同时牺牲修改性能的代价的。
但是我们要这样放弃吗？显然不是，因为实际的业务需求可能不会有这么复杂，对于实际情况下，我们还是可以建立合适的索引的，这些只是让我们在做索引时，要多考虑，多做运行的状况的比较。
锁定等待
我们知道查询的开销主要包括两个部分，一是查询本身的计算时间和查询开始前的等待时间，索引影响的计算时间，而锁定等待影响的是第二个。同时锁机制是保证并发访问的一致性，因此我们必须在合理的利用锁。书中介绍了表锁定和行锁定，在大多数情况下，合理的情况下，降低锁的级别和粒度能提高性能，如果你一次性更新很多行，把行锁定升级为表锁定反而更可行。
此外，书中还介绍了mysql事务更新的机制、临时表、查询缓存、线程池和反范式设计方面给出了一些建议。当然，除了关系性数据库之外，非关系数据库或key-value库等，必要时也可以考虑。
数据库扩展
数据库的扩展首先先提到的是主从复制，主流数据库都支持这个特性，通过这个特性，我们对主数据库所有的更新操作都会及时的复制到从数据库。在数据库分离之后，我们就可以更进一步，实行读写分离，把所有的读取的操作分离到从数据库，如果读取的压力过大时，我们还可以建立多台从数据库来保证服务。
读解决了，如果写操作频繁，这时主数据库服务器就成为我们系统的瓶颈，我们此时就可以考虑数据库的垂直分区：我们数据库中的一些表结构不存在必然的联系或不存在join的查询，我们就可以考虑把这些表结构分离到不同的数据，比如我们可以把用户的博客内容和用户的好友关系分离开。同样分离出去的数据库也可以建立自己的主从复制和读写分离体系。
某个时候，用户博客的数据库的主服务器，再次无法担写操作的压力，当我们的垂直分离已走到尽头，水平分区出现了：我们对同一数据表中的记录通过特定的算法分别保存到不同的数据表，从而分离到不同的数据库。相对于，垂直分区我们应该根据数据之间的关系，水平分区则涉及到一定的算法和规则：如我们可以根据用户userid，把用户userid为奇数的用户的博客和为偶的用户的博客进行分区，当然我们还可以按一定的范围，再或者建立个映射关系。这就要考虑网站的实际情况和架构师当时的心情了。
最后
《构建高性能的web站点》读书笔记完结，再次推荐下这本书，讲的挺全面的。