OurMySQL

百万记录级MySQL数据库及Discuz!论坛优化

最近，帮一个朋友优化一个拥有20万主题，100万帖子，3万多会员，平均在线人数2000人的Discuz!论坛，采用Linux2.6+Apache2+mod_php5+MySQL5，服务器配置为双至强+4G内存，优化前，系统平均负载（load average）基本维持在10以上，MySQL的CPU占用率基本在90%以上，优化后，系统平均负载降到0.5以下，MySQL的CPU占用率很少有超过10%的时候。优化前YSlow得分只有35分，优化后YSlow得分86分。

继续阅读全文...

数据库的设计方法!

下述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。

继续阅读全文...

MySQL排序原理分析

以上两种方法，一种是老方法，另外一种是改进的方法。两种方法各有自己的优缺点。第一种方法，对sort_buffer_size的占用主要是排序的字段以及一个row pointer,这种方式对排序内存的占用较少，可以有效的减少磁盘排序，但坏处也相当的明显，要对表进行两次扫描，第二次是要根据排好序的字段的row pointer指针回表取数据，这种方式，随着排序行数的加大，对时间的消耗将会变得无法忍受(类似于oracle的nested loop)。老方法受到两个参数的影响：sort buffer size以及read_rnd_buffer_size。

如果采用改进型方法,这种新方法，只会扫描表一次，由于在一次扫描表时，取出了查询所有需要的字段，不仅包括排序字段，全都要放在排序内存(sort buffer)里,对排序内存的需求量比较大一些，如果是对少量结果集进行排序，这种新方法与老方法的性能差异并不会太明显(此前提是在并发量较低的情况下，如果这样的排序的SQL执行频率较高，那么新方法相对老方法，优势也比较明显）,因为老方法在经过第一次数据扫描后，需要排序的少量的行都在内存里，第二次也只是到内存里取，这个速度相对来说，还是比较快的。如果是大量行的排序，新方法的优势便会体现出来。

对于少量行的排序，这个工作，还是交给应用层来做最合适，也多不了几行代码。

继续阅读全文...

MySQL 性能优化（INNODB下修改表结构）

最近碰到一个奇怪的问题：在MySQL中修改一个大表的结构（增加一列），发现修改缓慢无比，表是用的INNODB引擎，大小大概6G的样子！按道理修改表结构应该会很快（因为CPU耗费不是很大，无非就是读就数据写入新的文件），由于执行时间超出了预期，所以该想办法解决了。

继续阅读全文...

完全优化MYSQL数据库性能的八个方法

完全优化MYSQL数据库性能的八个方法

继续阅读全文...