December 2008 Archives

• 一个表中不止有一个timestamp格式字段的情况下，没法使用自动更新的timestamp
• 在mysql 5.1.22之前的InnoDB,使用auto_increment会导致表级锁定
• mysqldump -d是仅导出DDL，-t是仅导出内容, 在库后添加一个空格和表名，可以单独导出某个表
• mysqldump可以使用where条件来导出部分记录
• mysqldump -T很强大,具体的mysqldump中文说明文档可以参见这里
• mysqldump默认是将内容写入到内存中,然后一块导出,使用-skip-opt和-quick参数可以快速导出,但是要注意锁表
  
• mysql -uusername -ppassword --Pager=less可以在命令行下使用less分页，也可以使用more等，在系统变量中定义PAGER也可以实现这个效果

以下信息基于Google搜索引擎:

支付成本列表

充值方式	充值金额	渠道成本	实际收益	备注
支 付 宝	1.00	0.015	0.985	年费 1800.00
网上银行	1.00	0.01	0.99
神 州 行	1.00	0.12	0.88
声讯电话	1.00	0.58	0.42	溢价销售，以具体定价为准
竣网卡通	1.00	0.25	0.75
盛大点卡	1.00	0.20	0.80
征途点卡	1.00	0.28	0.72
电信聚信	1.00	0.15	0.85
联华OK	1.00	0.15	0.85

按照提示会依次要求输入

• ZendOptimizer的安装位置 #/usr/local/Zend
• php.ini的位置 #/etc/php5/apache
• 是否使用Apache #是
• apachectl的位置 #默认/usr/sbin/apache2ctl
• ApacheBinary的位置 #默认检测不到,应该是/usr/sbin/apache2

然后问你是否要重启，zend自行重启失败能grep出来就OK

1.MySQL如何生成Query Cache

• MySQL Query Cache是内容为 select 的Key=>Value ResultSet, Cache 使用完整的SQL字符串做 key, 并区分大小写,空格等,两个SQL必须完全一致才会导致Cache命中.
• prepared statement永远不会cache到结果,即使参数完全一样.据说在 5.1 之后可能会改善(慎用mysqli的stmt和prepare)

• where条件中如包含了某些函数永远不会被cache, 比如current_date, now等.
• date 之类的函数如果返回是以小时或天级别的,最好先算出来再传进去(和做主从的时候尽量不要now一样)

select * from Table where time=current_date -- 不会被 cache
select * from Table where time='2000-01-01' -- 被cache, 正确的做法

• 太大的result set不会被cache (取决于query_cache_limit)

2.Query Cache如何失效
一旦表数据进行任何一行的修改,基于该表相关cache立即全部失效.

3.Query Cache的性能

• cache 未必所有场合都能改善性能

当有大量的查询和大量的修改时,cache机制可能会造成性能下降.因为每次修改会导致系统去做cache失效操作,造成不小开销.
另外系统cache的访问由一个单一的全局锁来控制,这时候大量>的查询将被阻塞,直至锁释放.所以不要简单认为设置cache必定会带来性能提升.

• 太大的result set因开销原因不会被cache

太大的result set不会被cache, 但mysql预先不知道result set的长度,所以只能等到reset set在cache添加到临界值 query_cache_limit 之后才会简单的把这个cache 丢弃.这并不是一个高效的操作.如果mysql status中Qcache_not_cached太大的话, 则可对潜在的大结果集的sql显式添加 SQL_NO_CACHE 的控制.
query_cache_min_res_unit = (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

4.Query Cache的内存池使用
mysql query cache 使用内存池技术,不是通过操作系统,而是自己管理内存释放和分配.内存池使用的基本单位是变长的block, 一个result set的cache通过链表把这些block串起来.因为存放result set的时候并不知道这个resultset最终有多大.block最短长度为 query_cache_min_res_unit, resultset 的最后一个block会执行trim操作.

定长：空间浪费
变长：需清理碎片
block 小： 链表超长，访问大块数据效率低。

参考文章:
High Performance MySQL
High Performance MySQL中有关mysql query cache的说明
MySQL的Query Cache

几乎所有的防盗链功能，都是通过判断 referer 来实现的。通常的规则是，如果 referer 是本网站的某几个域的URL 或者 referer 为空时，则正常输出，否则给出一个出错图片。所以解决此类问题的方法就是通过伪造 referer 来突破外链限制!
在GReader里面也经常能遇到这种情况, 新浪博客,网易相册甚至Toplee这种个人博客等都做了图片防盗链, 看起来很是郁闷。
使用RefControl可以伪造refer请求,流程如下:

1. 安装 RefControl 扩展
2. RefControl Options - Add Site:
   • Site: photo.sina.com.cn
   • Action: <Block> (send no referrer)

这个方法同样适用于其他的在线RSS浏览器
参考信息:
HTTP Referer二三事
Google Reader 里看新浪博客图片

两个隐藏refer信息的网站:
hideref.com
anonym.to

原来找寻HttpD解决方案的时候搜索过Cherokee, 基本上和Nginx处于一个水平线上, 但是相比Nginx来说,Cherokee 的使用人数更少, 尤其是国内使用的更少。之前有使用LighttpD的经验, lighty某些稳定性及至支持, 和Apache的差距令我比较郁闷, 相比Nginx的文档及使用者, 还有张宴的博文对Nginx的推广, Cherokee更令人不放心。
今天在cnbeta上看到了Cherokee的相关介绍文章,希望在技术人员中能推广一下,毕竟多一个选择总不是坏事, 而没有理由的拒绝尝试新事物则代表了一个技术人员的技术生命的终结(by delphij)
另外期待一下Mathopd, 据说是gmail 帮助中心的解析支持