目前web2.0的程序，很大瓶颈是数据库的吞度量。不过，如何才能确定系统的瓶颈是数据库呢，因为只有确定数据库是整个系统的瓶颈，我们才有必要去优化他，毕竟，还有这么多需求等待我们去做。

　　如何确定数据库是瓶颈?

　　1 如果程序设计良好，有一个数据库操作逻辑层，可以从这个层的统计数据看到每个请求花费的时间，如果平均时间已经不能让你容忍的话，数据库已经是瓶颈了。

　　2 在数据库的服务器上使用top命令，看看mysql服务器占用资源的情况，看看机子的平均负载。

　　如果服务器的平均负载已经很高，mysql占用了块100%的cpu资源，说明mysql服务器很忙了。

　　3 在数据库服务器上使用iostat命令，看看磁盘IO，如果block住的操作比较多的话，说明数据库操作还是过于频繁了，磁盘都响应不急了。

　　4 建议打开mysql的慢查询日志，这样grep select看一下日志中的慢查询的数量，如果数量较多，说明慢查询的数量很多，需要进行调整了。

　　5 如果有一天数据库无法插入了，需要检查一下数据库表是不是过大了。32位的操作系统上一个表最大的容量是2^32这么大。不过还是建议增加一个数据库操作的逻辑层，在数据库操作的前后记录下操作的时间，进行统计上报，利用监控程序来报警相关负责人，这样可以及早的知道数据库是瓶颈，提前做出优化。

　　知道数据库是瓶颈了，如何来进行优化呢?

　　1 我们第一个想到是看看数据库的容量是不是太大了，如果数据库表太大的话，索引文件也会比较大，每次的更新操作就会更加的费时。需要考虑进行分库和分表了。

　　分库分表按照一定的规则来对数据库中的记录进行分区来存储，一方面可以做到一定的负载均衡，将请求平分下来，每个区段去独自承受;另一方面，分库分表可以使我们存储和操作更多的数据。

　　不过分库分表需要多之前基于单库的程序进行修改，存在一定的风险，因此，在程序设计之初就应该考虑到分库分表的需要，最好是将数据库操作层独立出来，便于扩展和更改。

　　2 如果数据库表不是很大，但是查询慢的话，我们需要检查一下我们的sql查询语句，利用mysql的explain语句看看是不是使用了索引，如果没有使用索引，那我们需要在相应的字段上建上索引，反复的使用explain，寻找到个一个合适的索引。

　　在建索引时需要考虑：

　　1)数据库的索引要做到越少越好。

　　因为每次更新都需要更新索引，索引过多就会降低写入的速度。

　　2)最窄的字段放在键的左边。

　　这样提高了索引中每一个点的基数，带来更好的索引读写性能。

　　3)尽量避免file sort排序、临时表和表扫描。

　　对于大表，全表扫描会导致大量的磁盘IO的操作，会导致操作非常的缓慢。

　　4)对于大表，尽量不要将索引建在字符串类型的列上，字符串的匹配是很费时的，需要付出很高的性能代价，如果一定有必要，建议对字符串列进行hash后取一个整形的值来进行索引。

　　3 如果更新操作有点慢，而读操作的响应要求不需要很及时的话，可以考虑利用mysql的主从热备来分担读写的压力。

　　毕竟对数据库的操作，写少读多。因此，我们将对数据库的写操作放到mysql的主服务器上，利用mysql的热备，我们在备份的数据库服务器上进行读操作，由于可以有多个热备mysql，于是可以将读操作分布在多个热备上面，从而将读操作均衡开来，提高读操作的性能。

　　4 缓存的使用

　　缓存是一切后台程序的根本，因为80%的请求是对应20%的数据，我们只需要少量的内存将20%的数据缓存起来，就可以大大的满足我们系统需求，何乐而不为呢。

　　1)mysql设置中尽量增加key cache，thread cache、查询的cache。

　　2)在应用程序层增加一个memcached这样的通用cache。

　　3)对于少量数据，但是操作频繁的表使用mysql提供的内存heap表，可以获得极高的写入和读取速度。