IO问题永远是数据库系统最大的问题，而导致这个问题最主要的原因就是数据量太大、读写太频繁....

通常情况下，读都是远大于写频率，而在大数据量的情况下，大数据量导致磁盘寻址时间的增加，频繁的读就会导致居高不下的iowait，除了做cache之外，最好的办法就是减少数据量。


用压缩的办法来减少数据量是个不错的办法，它能极大减小数据量，并且压缩解压成本较低，而且cpu横向扩展远比IO能力横向扩展容易的多。据了解，目前业内有不少正在使用这种压缩方法（例如对各种文档、blog等），但主要

针对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啊:)

   各位使用的时候要注意了

最开始使用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

   

    在infoq看到这一篇优化使用BigTable的原则与方针，觉得对做大规模数据库设计时有很大参考作用，特拿来与关系型数据库做一下比较。

  
    Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价，只有在以下情况下使用BigTable才能带来益处：

Mysql中的复制主要用于备份、分担数据读取压力、数据库可用性等。从数据备份上来说，这种方式是一种很不错的实时备份方案。而用在读取压力分担上，虽然也能达到很不错的效果，但是也有几个缺陷。比如写开销无法降低，因为无论slaver和master都需要进行相同的数据写入。还有就是复制过程中slaver会有延迟。下面我谈谈对于复制延迟的看法。

    这篇文章如题所述，只打算谈一下数据库表本身设计，同时讲到和表结构相关的性能和扩展性问题。下面讲到的东西大多是从实际经验中总结而来，算是对这项技术的一个反思。

   基本上在设计数据库表的时候，首先考虑设计要满足功能需求，这是最根本的，其次是满足性能需求，再次则是满足扩展性需求，这一点在大规模系统中是必须要考虑的。功能性需求比较容易满足，下面我主要谈谈对性能和扩展性需求的一些设计方法。

    没人不想速度更快，但是怎

        有谁知道像Google，Baidu等搜索引擎的索引数据怎么备份么？
        以及一些RSS阅读器里面的Feed和文章数据怎么备份？


    他们都有一个共同点就是数据量大，而大数据量下的数据备份绝对成了一个很大的挑战。在SD2China大会上，钱宏武谈到他在做搜狐社区产品的时候的一个关于数据备份的事。产品刚上线的时候他设计一个数据备份方案就是每天下午4点作

    我一直在思考像百度贴吧、youtube这种网站数据量那么大，但是访问又怎么那么快呢？百度贴吧帖子量多的吓人，比如一个“李宇春吧”就有几千万的帖子，但是访问起来是飞快。而youtube呢，平均每天大约有6w个视频上传上来，并且每天千万至亿的访问量。这些对于web服务器来说，使用windows 2003上的负载均衡应该能够解决问题，但是一直没有弄清楚怎么设计数据库的负载均衡。当然自己也凑合想了一个方案，如下：

基于SQLServer的分区视图方案，并不是真正意义上的负载均衡。

几本方案具体实施步骤：

1、

    比较这两个SQL
       第一种：

exec sp_executesql N'declare @ItemID bigint

                                   declare @CommentID bigint

                                   select top 1 @ItemID=ItemID,@CommentID=CommentID