1989年6月的民主运动

谈到六四，我最常遇到的一个问题，就是：假如八九民运成功，会是怎样？尽管历史已经发生，不能假设；但是这样的问题从来没有中断过，所以我还是想谈谈自己的看法。

要回答这个问题，首先就要定义什么是八九民运的“成功”。外界对八九民运最大的误解之一，就是“如果你们上台，就会比共产党更好吗”这类的质疑。这个冠冕堂皇的质疑其实完全是一个假问题，因为八九年的学生从来没有提出取代共产党，我们自己上台的主张，而且不管八九民运最后如何发展，也根本不可能出现所谓学生领袖成为国家领导人这样的事情。有些人拿这些莫须有的推测作为现实中的质疑理由，然后站在道德的制高点上评判历史，这是极大的荒谬。

成功，指的是达到目的。八九民运的政治主张最早是在1989年4月18日由包括我在内的学生代表在人民大会堂会见中共中央和国务院信访局领导的时候提出的所谓“请愿七条”，包括正确评价胡耀邦同志的是非功过，彻底否定“清除精神污染”“反对资产阶级自由化运动”，为在运动中蒙受不白之冤的公民平反；公布国家领导人的年薪收入及一切形式的收入；允许民主办报刊，新闻自由，限期解除报禁；增加教育经费等等。在运动发展过程中，陆续有更多的政治主张出现，但是大致的范围也与上述“七条”有类似之处。但是我认为，如果要确认什么是八九民运的成功，还是应当以5月13日学生绝食提出的两个条件作为权衡标准，因为绝食导致学生运动转化为全民民主运动，之后全国的声援力量都集中在要求政府接受学生的绝食要求上，因此，假如八九民运成功，那么就意味着，政府最终接受了绝食学生的两个要求。

这两个要求是：第一，要求政府迅速与北京高校对话代表团进行实质性的，具体的真正平等的对话；第二，要求政府为这次学生运动正名，并给予公正评价，肯定这是一场爱国民主的学生运动。

因此，讨论“假如八九民运成功”这个问题，就是要讨论，如果政府开始与学生对话，并肯定了学生运动的爱国性质，对于中国未来的发展会有什么样的影响。我认为，最大的影响会是以下三个：

——讲述给里德听的我的家谱

伦 纳德·里德，秋风译

附：米尔顿·弗里德曼为本文写的导语

我是一支铅笔——最普通的木杆铅笔，只要是能读会写的男女老少都最再熟悉不过的铅笔*。

写字是我的职责，也是我的业余爱好；那是 我的全部工作所在。

你肯定有点奇怪，我干嘛要搞一个什么家谱。好吧，我来解释一下，嗯，首先，因为我的故事很有 趣。其次，我是一件神秘的东西——要比树 木、比日落、甚至比闪电要神秘多了。不过，很不幸，那些用我的人把我看得平淡无奇，就好象我完全是自己钻出来的，一点背景都不需要。这种目空一切的心态把 我归入大路货的档次。这实在是一个令人伤痛的错误，而如果人们一直犯这种错误，难免会出乱子。因为，博学的G. K. Chesterton曾经说过：“我们会因为缺乏好奇而毁灭，而不会因为期望奇迹而毁灭。”

《时间管理–给系统管理员的》这本书之前出英文版的时候就看了点开头，现在出了中文版的PDF终于算是全部看完了。
看后的感受特整理如下。
使用笔记（将其它需要处理的事情记录在笔记上），将脑力集中在当前事务中，而记录需要处理的事情就会让大脑只专注于当前，而不会去想还有其它的事情需要处理。那样只会让自己分心。
将脑力集中在重要的事情上，这个对于主次不分的我还是很有用处的。
形成自然习惯，按照一个资料的说法，如果你连续21天做同样的事情，那你就会对那个事情形成习惯。
迟早都要做的事情，晚做不如早做。
每天早上花5分钟计划一天。
减少中断，努力在被中断前完成当前的事情。
把需要记住的事情在大脑中清除，而把这些事情记录在笔记上或者电脑上。
关闭IM和EMAIL，我自己曾经试过这样一天，果然效率提高很多。
每天上班的第一个小时用在重要的工作上。这个可能每个人不一样，我自己是下午3点到5点是效率最高的时间。
当有人来干扰你的时候，你可以进行委派给其他同事，记录下事情，或者立即执行。
永远测试你的工作。这个我是深有体会的，特别是这次在做ETL迁移的时候，很多都是很细节的东西，涉及到的步骤又特别多，所以必须对于每一步都要进行测试，不然以后排错就麻烦了，也会造成统计数据不准，不能出很多同事的KPI了。
放手开始做，事实不会那么难的。其实对于SA，DBA很少有没法解决的技术问题，我们又不是研究型工作，需要攻克什么课题。
与其它相关部门进行沟通。这个是很有必要的，作为一个DBA需要跟技术沟通，有时候产品设计不合理导致数据库压力非常大，这个时候还要跟产品沟通。有时候要跟运营直接沟通。
创建自己的例行公事：重复没有安排到的事情，维护工作，人际关系与职业风格，耽误很久时间时就开始行动吧。
对于低优先级的事情偶尔可以进行忽略。
开发新技能，并能持续更新。这个算是技术人员的悲哀了。
时间管理里面很重要的一部分就是目标管理，有分今日目标管理，短期目标管理和长期目标管理。
写下你的所有目标，并定期进行回顾。要是你不写下，你也许会忘记。
制定的目标应该可以测量：目标需要有具体的结果或者数量值来作为测量标准。
目标应该设有截止日期。
目标设置可以分为1个月，1年目标以及5年目标。
对于来自上司的请求你还是能马上完成还是尽力的马上完成，毕竟他是最终考核你的人。
管理你的上司：让他协助你发展你的职业生涯，你要跟你的上司沟通你最终的目标等等。
知道何时使用往上委派，了解其目标并做出贡献。
根据客户期望来排定事务的优先级。
面对压力时我还是建议你没小时都出去走走，这样会减缓很多眼里。
余家，冥想，按摩都是很好的减压方式。
如何管理email
1 过滤器
2 删除未读邮件（如果一个事情很紧急你肯定会立刻读，对于那些长久没有读的邮件就应该立刻删除）
3 使用IMAP协议，这样在邮件服务器上也会使用过滤器。
4 对于每一封邮件我们必须一下子看完，然后做决定。
常见的浪费时间的事情： 工作表内有垃圾内容，订阅的邮件列表太多等等

书写文档

我见过很多SA和DBA都不喜欢写文档，感觉这个太费时间。

书写文档分为2种，一个是面向客户的储藏库：把你客户要用到的流程写成文档。这样省去了这些客户以后再来找你，中断你自己的工作。

内部IT储藏库，你的内部所需要协助做好的工作信息。

其实无论是对于系统管理员而言，还是对于数据库管理员，或是其它IT支持类的工作都免不了被打扰，所以进行时间管理还是很有必要的，当然文中的作者是从较高的层次来说的，毕竟作者的级别高，跟我们这种普通员工关于时间管理的内容还是很不一样的。
作者每天处理的事情都是很久之前可以确定的，确定一个大目标来进行1周的处理。
而作为我们普通员工时间管理的意义就是看看自己每天工作都花在了哪些地方，这也是刚开始做时间管理必须要经历的一个过程。比如我现在每天都用evolution来写下每个小时每天都在做哪些工作，这样每周报告和总结的时候有很多依据来进行。而等过了这个过程时候就要进行更多的规划性的内容。而不是一直陷入在日常事务性工作。
就好比我从上个月开始就想要完成的MYSQL DRBD的测试工作，可至今没有完成，从本周的时间记录来看，大部分时间都花在了对于产品和运营的支持上了，而对于DBA本职工作，关于数据平台ETL的迁移花的时间只有30%左右。 可见还是被经常打断，但是很多时候会自我中断，有时候会参加同事的讨论，有时候会上上论坛看看新闻等等。

mysql的单点一直是一个让人很烦恼的事情，特别是master的单点。
现在外面的解决方案主要如下： 双master方案，heartbert(HA)+rhcs(分布式文件系统)，heartbert(HA)+DRBD.
双master存在的问题是master有2个IP，这样意为着前端需要指向2个的masterIP，同时bin-log也是双向同步的，会不会比单向同步的量更多呢？
第二种方案是挺不错的，但是必须要分布式文件系统，要是实在不行就可以用NFS来代替，但是这样存在的问题就是数据文件是单点，所以必须使用分布式文件系统。
第三种是关键是DRBD，这个是在网络层做RAID1，在A机器上收到数据后DRBD会写到本地硬盘上，同时通过网络传输到另外一台机器上。这样保证了2台机器的一致。特别是DRBD传输的时候有多种协议可以选择，但是一般看到网上大家都是使用协议C（C表示收到远程主机的写入确认后,视为写入完成）
DRBD的架构如下：
今天在high scalability有个文档专门比较各种mysql HA的方案。基本上大家可以根据这个比较来做自己合适的的MySQL HA了
2010-05-09

第三章 架构优化和索引

第三章的主要是说合理使用不同的数据类型和索引。主要需要注意的内容有如下：

1. 通用原则
   1.1. 数据类型更小通常更好。
   1.2. 数据类型越简单越好
   1.3. 尽量避免使用NULL,要是有必要用NULL，那也可考虑使用0来进行代替。 创建表的时候定义好not null default 0。
   1.4. DATETIME和TIMESTAMP都能保持同样数据类型：日期和时间，精度为妙。而且TIMESTAMP使用的空间只是DATETIME的一半，TIMESTAMP使用4个字节，DATETIME使用8个字节。而且TIMESTAMP还能保存时区，拥有特殊的自动更新能力，但是TIMESTAMP的范围要比DATETIME要小的多。TIMESTAMP类型只能保存1970年1月1日零点到2038年。而DATETIME却能保存1001年到9999年。
2. VARCHAR和CHAR
   2.1. 大家都知道VARCHAR是可变长度的，而CHAR是定长的。
   2.2. 使用VARCHAR(5)和VARCHAR（200）保存’hello’占用的空间都是一样的。但是VARCHAR(5)只会使用较小的内存空间，因为MySQL通常会分配固定大小的内存块来保存值。
3. 索引对于查询的性能影响是非常大的。下面先介绍下索引类型。
   3.1. B-TREE索引，大部分MySQL存储引擎都支持B-TREE。除了ARCHIVE直到5.1才支持。
   3.1.1. 存储引擎使用了不同的方式把索引保存在磁盘上，它们会影响一定的性能。例如MyISAM使用前缀压缩以减少索引，而InnoDB不会压缩索引，因为它不能把压缩索引用于某些优化。
   3.1.2. B-TREE通常意味着存储是有序的。
   3.1.3. B-TREE索引能够很好的用户全键值，键值范围或者键前缀进行查找（最左前缀）。
   3.1.3.1. 匹配全名，如 where name=’timo’
   3.1.3.2. 匹配最左前缀， 如 where name like ‘tim%’
   3.1.3.3. 匹配范围值，如 where name between ‘tim’ and ‘timo’
   3.1.3.4. 精确匹配一部分并且匹配某个范围内的另一部分，如 where name=’timo’ and age between 25 and 30
   3.1.3.5. B-TREE索引通常能支持至访问索引的查询，它不会访问数据行
   3.1.4. B-TREE索引的局限性
   3.1.4.1. 假设有如下的索引 key(first_name, last_name, age)
   3.1.4.2. 如果查找没有从索引的最左边开始，它就没有什么用处。比如where first_name like ‘%mo’ 这样的查找是不走索引的。
   3.1.4.3. 不能跳过索引中的列, 如查找 where first_name=’timo’ and age = 25, 如果建立的是上面这样的联合索引，又跨了last_name，那就不会走索引了。
   3.1.4.4. 存储引擎不能优化访问任何在一个范围条件右边的列。如查找
   where first_name=’timo’ and last_name like ‘s%’ and age=25。访问就只能使用索引的前2列，因为like是范围条件。
   3.1.4.5. 一些局限并不是B-TREE固有的，而是MySQL查询优化器和存储引擎使用索引的方式造成的。
   3.2. 哈希索引(hash index)
   3.2.1. 它值对使用索引中的每一列的精确查找有用。所以很少用，在MySQL中是有Memory存储引擎支持显式的哈希索引。
   3.2.2. 由于hash index是给每个键值建立一个哈希表，所以它的查找速度是非常快的，但是也会有很多局限性。
   3.2.2.1. 因为索引只包含了哈希码和行指针，而不是指本身，MySQL不能使用索引中的值来避免读取行。
   3.2.2.2. 不能进行排序
   3.2.2.3. 不支持部分键匹配
   3.2.2.4. 只支持使用 =, in() 和<=>的相等比较。
   3.2.2.5. 发生碰撞的时候存储引擎必须访问链表中的每个指针，然后逐行进行数据比较，以确定正确的数据。
   3.2.2.6. 如果有很多碰撞，一些索引维护操作就会很慢。
   3.3. 空间（R-TREE）索引
   3.3.1. 只有MyISAM支持，可以使用GEOMETRY这样的地理空间数据类型，必须使用MySQL GIS函数进行查找。
   3.4. 全文索引
   3.4.1. 全文索引只有MyISAM支持。是从文本中直接找关键字，而不是从索引中进行比较。全文索引用户MATCH AGAINST操作。
   3.5. 高性能索引策略
   3.5.1. 隔离列
   3.5.1.1. 下面2条语句是不会使用索引的

   1 2 3 4 5 6 7 8 9

   where actor_id + 1 = 5 where TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col) <= 10 ``` 3.5.1.2. 下面2条是针对上面2条进行修改使用索引的 ```sql where actor_id = 4 where date_col >= DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) ``` 3.5.2. 前缀索引和索引选择性 3.5.2.1. 当某一列特别长的情况下，如果给全部长度建索引，那样会增加索引的大小，而只做很短的前缀索引，虽然节约了空间，但是会增加选择性。所以建前缀索引必须让选择性接近于全部长度的选择性。 3.5.2.2. 平均来说前缀的选择性能接近于0.31就可以了。

   sql select count(distinct city)/count() from db_name.table_name; select count(distinct left(city, 3))/count() AS sel3, count(distinct left(city, 4))/count(*) AS sel4 from db_name.table_name;

3.5.2.3. 只看平均选择率在特殊情况是不够的，比如在数据分布非常不均的情况下。  
3.5.2.4. Alter table db_name.table_name add KEY (city(7)) 这句就是只对city这一列的前7个字母进行索引。  
3.5.3. 聚集索引（clustered indexes）  
3.5.3.1. 在InnoDB中聚集索引实际上在同样的结构中保存了B-TREE索引和数据行。聚集的含义就是指实际的数据行和相关的键值保存在一起。每个表只能有一个聚集索引，因为不可能一次把行保存在两个地方  
3.5.3.2. 在MySQL中只有SolidDB和InnoDB是支持聚集索引的。  
3.5.3.3. InnoDB是按照主键（Primary Key）列进行聚集。如果没有定义主键，InnoDB会试着使用唯一的非空索引来代替。  
3.5.3.4. 聚集索引有助于性能，但是也会导致严重的性能问题。总的来说它有如下的优点：由于把索引和数据都保存在一棵B-TREE中，因此查找数据会比通常的要快。  
3.5.3.5. 聚集索引也有如下的缺点：会导致I/O密集，插入速度慢，更新索引列慢，插入新行会进行分页，这样导致占用更多的磁盘空间。第二索引会比预想的大，第二索引访问需要两次索引查找。  
3.5.3.6. 在InnoDB中是根据主键来进行顺序插入的（这个跟InnoDB的数据布局有关），所以主键最好是一个自增的值，与应用程序无关。  
3.5.4. 覆盖索引（covering indexes）  
3.5.4.1. 包含（或者覆盖）了所有满足查询需要的数据的索引叫覆盖索引。  
3.5.4.2. 索引记录通常远小于全行大小，因此只读取索引就能极大的减少数据访问量（这个跟聚集索引的优点一样）  
3.5.4.3. 索引是按照索引值进行排序的。  
3.5.4.4. 大部分存储引擎缓存索引比缓存数据更好（除了Falcon）。  
3.5.4.5. 对于InnoDB覆盖了查询的第二索引在主键中避免了另外一次索引查找。  
3.5.4.6. 覆盖索引必须保存它包含列的数据。  
3.5.4.7. 当发起一个索引覆盖的查询，用EXPLAIN会在extra列显示Using Index  
3.5.5. 为排序使用索引扫描  
3.5.5.1. MySQL有两种产生排序结果的方式，使用文件排序（Filesort）和扫描有序的索引。如果EXPLAIN的输入type列的值是index。那说明MySQL会扫描索引。  
3.5.5.2. 只有当索引的顺序和order by字句中的顺序完全一致，并且所有列排序的方向（升序或降序）一样才可以。如果查询连接多个表，只有在order by 字句的所有列引用的是第一个表才可以。  
3.5.5.3. 假设有如下表：  
```sql 
CREATE TABLE rental ( ………… PRIMARY KEY (rental_id), UNIQUE KEY rental_date (rental_date, inventory_id, customer_id), KEY idx_fx_inventory_id (inventory_id), KEY idx_fx_customer_id (customer_id), KEY idx_fx_staff_id (staff_id), ………… ) 

3.5.5.3.1. 下面的这几个语句是使用到索引的。

WHERE rental_date='2010-05-02' ORDER BY inventory_id desc; WHERE rental_date > '2010-05-02' ORDER BY rental_date, inventory_id; 在where字句是范围的时候需要用最左前缀索引进行排序。 

5月7日更新

http://t.qq.com/invite/9e0f171d0f07bda2a419

http://t.qq.com/invite/5c7758cfa99b35b7494b

http://t.qq.com/invite/6d1e0a6e6907388fc813

5月6日更新

http://t.qq.com/invite/80c5e325e294a2fa61ef

今天算是把中国几个主要网站的微博都给注册上了，加上以前的twitter, fanfou, jiwai, zuosa，而现在这个队伍又增加了163, sina, qq, sohu都4大门户的。

其中QQ的还算是在内测阶段，其它都已经开放了，而之前的twitter, fanfou, jiwai都因为种种种原因在中国消失了。真是可惜了饭否，要不是新疆事件的发生，我想王兴现在应该是领跑了国内微博市场了。而现在微博只是成了极大门户之间一个小功能而已，做不做的起来那是随便，就跟SOHU的白社会现在基本算了挂了，而SINA的朋友在内测阶段就挂了。因为SNS比较容易聚集人气，一旦人家做大了，后来者很难救超越了，除非出现杀手级应用，比如KAIXIN001的MSN和QQ的好友导入功能。

从截止今天来看，SINA还是在主推它的微博产品，很多名人也被导入到微博中，而很明显SINA的微博会再次像它的BLOG产品一样沦为名人的意见栏，很多粉丝在后面留言，而粉丝们很少会在SINA上建立自己的博客。而它的微博也明显也有这样的特质，可能对于名人来说写个博客太麻烦了，要写那么多字也难为这些人，虽然估计这些博客也不是这些大忙人自己写的。

而QQ还无法在首页找到微博的影子。

163好像挺努力的推自己的微博的，还在首页最下方整了一块地方来推这个，而SOHU只有个目录链接。

4大门户的微博之战还刚开始，而微博技术上并不难实现，主要是如何实时找到最热的关键字等等。

昨天晚上世博开幕了，20多分钟的烟火表演甚是漂亮，我想我要是在现场的话估计可以更多更好的画面。本来一直说世博倒计时多少天就是离我回家还有多少天，可最终我没有回去。要是回去的我想我也在滨江大道的人群中。
其实要说世博应该算是一个早已没落的盛会了，要说它的最光辉的时刻还是刚开始举行那几届，造就了伦敦的水晶宫，巴黎的埃菲尔铁塔灯，而最近一次让我又映像的还是几十年的日本世博会。
不过对于我们很少组织过世界重大盛会的国家来说，世博会还是不错的。长达半年要是在比较小的国家估计也就前几个星期会参观的人，而在这里根本不用担心人少。
之前看过一个笑话，内容是这样的，北京举办奥运会前汶川地震，上海举办世博之前是玉树地震，国际足联有意将下届世界杯放在中国举行，帝国主义亡我之心不死啊。
其实对于普通上海市民来说世博对自己的影响很小（除了因为世博拆迁的人们）。胖子家居然还成为了世博接待人家，看来在市中心有套别墅还是很牛B的。
今日老爸从上海发来急电，今日上海交通全面瘫痪，话中无不显露出一位开电动自行车人士的得意的心情。还好上海地铁交通非常发达，而且现在有了月票的出现，对于地铁上班族影响不大，可对于公交车出行的，那简直就是悲剧了，北京今年开2会期间的2个礼拜，三环每天都是狂堵，导致上班经常迟到。
据说世博结束后有些建筑会拆，我想本来有些就应该拆了，什么可口可乐馆这样的企业馆本来留着也没有实际的意义，但是像有些国家馆比如荷兰馆和英国馆，德国馆还是有保留的价值的，据说不是市政府各个机构会在盛会结束后迁入世博园区进行办公。那人民广场那个大厦作为什么进行使用呢？
哦，今天是51劳动节了，今天家里来了客人，天气很热，不想出门，换上夏装了。好快啊，一下就感觉到了夏天了，上周还有冬天的感觉呢。时光真的很快，去年这个时候来北京才没多久呢，这就一下1年就过去了。
任时光匆匆流去，我只在乎你。亲爱的。
2010-05-01

为了省去再进行手动编译，就直接把一个编译完成的虚拟机copy成另外一个，但是mac地址却变成一样了，这样没法连接了。放狗搜索了一下找到如下方法
vim CentOS-test1.vmx
修改如下2行
ethernet0.generatedAddress = “00:0c:29:50:6f:98”
uuid.bios = “56 4d 84 12 57 12 a7 6e-64 ac 83 5c fb 50 6f 98”

我自己就修改了最后一位把7改成8就可以了。重新启动虚拟机一切正常。

2010-04-27

如何在apache中添加中文域名
比如www.中国.com
打开CNNIC的中文域名在线转码页面，选择转成punycode，输入待转中文域名，转换后再绑定。 转码地址http://cnnic.cn/html/Dir/2003/10/29/1112.htm
然后转成了 www.xn--fiQs8S.com
ServerName www.xn--fiQs8S.com
ServerAlias www.中国.com

难得会上企业的网站，但是现在是车展原因上了一下一个企业的网站，发现现在企业网站很多都是flash来完成的，这个公司的主要web server应该是IIS,至于什么版本实在看不来，但是有些静态页面是用apache的，在更前端就是CDN了，帝连还会接这样客户，看来只要是网站他们都接啊，不过这种客户应该不像我们以前每天都那么多事情的。
说说下载吧，他们居然下载也是通过flash进行控制的，虽然我装了迅雷，但是点击下载不会自动启动迅雷，弹出的目标窗口也是flash做出来的。flash下载就会在本地创建一个临时文件，至于走什么传输方式没有dump也不大清楚。而且中断如何进行控制也不知道，能否续传也不知道。呵呵，只是难得碰到这样的下载方式。
2010-04-26