网站全体优化之数据库优化
发布时间：2022-03-03 18:03:38 所属栏目：搜索优化 来源：互联网
导读：目前web2.0的程序，很大瓶颈是数据库的吞度量。不过，如何才能确定系统的瓶颈是数据库呢，因为只有确定数据库是整个系统的瓶颈，我们才有必要去优化他，毕竟，还有这么多需求等待我们去做。 如何确定数据库是瓶颈? 1 如果程序设计良好，有一个数据库操作逻
|
目前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 数据库的设计上进行优化 对于传统的数据库设计我们讲究建模范式，避免数据的冗余从而导致脏数据。然而在我们实际的应用中需要根据情况来使用第三范式的一些规则，对于一些频繁需要在多个地方出现的数据，如同一个论坛这种用户和主题以及回复等有关联的应用中，如果我们将用户同主题和回复分开来存储，每次查询一下一篇文章或者一个回复的情况都需要对用户表和主题表或者回复表进行联查，如果数据量小的话，这样联查的性能还是可以接受的，如果表大一点，上了3、4十万以上的数据，联查的速度就会比较慢了。  （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号