IO问题永远是数据库系统最大的问题，而导致这个问题最主要的原因就是数据量太大、读写太频繁.... 通常情况下，读都是远大于写频率，而在大数据量的情况下，大数据量导致磁盘寻址时间的增加，频繁的读就会导致居高不下的iowait，除了做cache之外，最好的办法就是减少数据量。 用压缩的办法来减少数据量是个不错的办法，它能极大减小数据量，并且压缩解压成本较低，而且cpu横向扩展远比IO能力横向扩展容易的多。据了解，目前业内有不少正在使用这种压缩方法（例如对各种文档、blog等），但主要

历时2周的上线终于算是完成了，虽然算不上是完美，但也总算基本顺利。过程中出了几次问题，但总算万幸没有出现大漏子，及时根据问题调整方法，逐步解决了问题。 如果要算上上线前的一些上线准备工作，总时间接近3周了，除了整个系统第一版的上线外，都没有那么费心过。虽然在以前工作也有过通宵上线的经历，但是系统规模却小得太多了，一个晚上就全搞定。 上线这档子事，说简单的话就是个体力活，拿着新代码发布出去就可以。说复杂的话那就是需要耐心、细心、全局观、细节掌控能力、系统熟

接文章：PHP里使用引用变量时容易犯的错 中的示例    foreach($arr as &$element) {        //modify $element    }    当循环操作完后，你再次调用了某个复制或者函数来保存$arr数组，例如：    set_var("arr", $arr);       这时候你认为被设置的$arr就是你想要的那个

一个场景：    foreach($arr as &$element) {        //modify $element    }    这种用法是最近常见的，但是这里隐藏一个严重的问题。由于$element变量的作用域是在整个函数（假如这个循环是在某个函数里），如果$element这个变量被foreach这个循环之后的代码再次使用并对其作修改操作时，问题就发生了。因为在循环里$element是个引用变量，如果再对$element赋值那么相当于修改了原有$element所指的内容，例如：

针对select * from table where col1 > number order by col2 desc。 其实按照常规的方法可以这样设计：key(col1, col2) 但是这种办法在mysql里不算是理想的，where条件里限定索引前部分是一个范围的情况下后面的order by还是会有filesort。如果where条件里限定索引前部分是一个常量，那么order by就会有效利用索引。例如：select * from table where col1 = number order by col2 desc，explain的结果就不错。 为了让它能够利用上索引并且消除filesort，可以这样设计 索引：key(col2,col1)

莫名奇妙的server gone away发生了，你怎么定位错误？我看在mysql下很多时候就靠猜了， innodb数据文件和表结构不匹配？ 配置错误导致内存空间不够？ .... 在我发现的好几次奇怪的mysqld挂掉后再重启的情景里面，mysql都没有记录出错信息，怎么办？只有靠猜了，这完全就只能靠经验办事了..... 这个错误日志确实有点弱。

继上次 binlog切换时会阻塞更新 ，最近还发现它不光阻塞更新，如果设置了replication那么它对从库的查询也有影响。       在binlog切换时，会有一个Rotate_log_event产生，而slave同步到此event后也会让Relay-log切换。由于mysql写这种日志都是写入系统缓存后就不管了，导致切换文件时需要对旧文件进行fdatasync，这时候瞬间io压力会过大，耗时较长。这种情况

真是太久没来写博客了，偶尔心里似乎有些感觉像欠了什么似的，但是没啥可写也感觉不想写，因为我已经定位此博客为技术路线，不愿其他的事情掺进来。言归正传，说说最近干的一些事吧。     从我使用mysql以来，我见过的都是用myisam作为存储引擎的首选，并且mysql doc也对myisam表扬有嘉，所以在大部分时候我都使用myisam。而在最近的一些测试中，myisam却没有想像中那么优秀。     确实myisam更新速度非常快，因为结构精简

这两个类型，如果只存储hello这个字符串的话，存储空间都没有区别的都是6bytes。    但是真没有区别么？其实是有的，mysql在处理数据的时候需要分配内存，而内存的分配都是fixed-size的，所以它只能按照最大的可能来分配，这样varchar(10)和varchar(100)就差别大了。而blob/text字段在处理时内存分配则有所不同，mysql会按照已经发现的最大长度来分配内存。如果查询时有filesort，处理是类似的。    所以字段长度只要是满足了需求，那么设置的尽可能小是没错的。

bug描述在 http://bugs.mysql.com/bug.php?id=25420， 字符比较的问题我们已经上过好几次当了，特别在混合字符集环境下的时候，这更是一个难产的问题。    天知道哪天能够统一到utf8啊:)    各位使用的时候要注意了

版本5.0.51b-log，在max-binlog-size设置为700M或者更大时（这个值可能跟硬件性能有关），当binlog达到设置上限并切换成下一个binlog时，所有的更新语句就会被阻塞，不管多简单的语句。

以前在做鲜果的时候，我就觉得翻译这个东西在阅读器里面会相当有用。在的互联网上，阅读和翻译已经是分不开的一对了。很早的时候有到阅读器推出了一个翻译功能，遗憾的是，那只能翻译一个词。现在看到Google Reader推出这样的功能，不过Google Reader的实现也不如人意，因为它只能从阅读器点到原文的时候给你翻译。    http://www.cnbeta.com/articles/69443.htm

最开始使用SQLServer，我喜欢这么用SQL：select * from table1 where id in (select table1_id from table2 where table2_filed = xxxx) and table1_field = yyy; 这里的一个查询其实会分为两个查询，对table1和对table2的子查询，这样写能让每个查询都尽量使用索引。    曾几何时，使用mysql的时候用explain分析查询，发现mysql里面的子查询很慢，而mysql文档里很多时候也推荐使用join，于是我认定了mysql的子查询实现的很烂，以后的程序里面都用join了。例如上面的查询我就写成：select a.* from table1 a join

如果你不小心用rm -rf xxx删除了文件或者整个目录，在ext2文件系统上是可以恢复的。因为文件数据没有被实际删除，只是索引被删除了，文件被误删除之后，应该马上停止创建、修改等文件操作，因为他们有可能会覆盖以前被删除文件所占用的磁盘空间，这样就没办法恢复了。     如果只有一个文件，那么运行：             debugfs /dev/sda2; // /dev/sda2是你要查看的设备

自从ajax兴起之后，页面加载速度就逐日下降。当然你可以说页面复杂了，js代码多了，所以速度下降了，但这并不是理由。自从上次用过safari之后，我就更加证实这一点，因为js在复杂，都还是达不到后端代码的复杂程度，后端页面能做到100ms以下的加在速度，浏览器上为什么不能？       现在尝试了Google Chrome，感觉浏览器速度又上了一个台阶。虽然Chrome短时间内无法达到别的浏览器的普及率，但是它让我看到了希望。看到了RIA的希望。

加为好友

syt1507	生活大看台
weholy	GoodtigerZhao
flyingse	yansunrong1129
wuyun_mm	code4fun

已有人次访问本空间   什么是RSS？