在给 MySQL 数据库访问层增加新功能时遇到了这样的错误：

1

ProgrammingError: (2014, "Commands out of sync; you can't run this command now")

之前零星地见到过几次，因为发生频度很低，就没有太在意，这次找了一下原因，MySQL 文档对 Commands out of sync 错误的描述是这样的：

遇到了几例 MySQL 没用使用预期索引的问题，读了些文档之后，发现 MySQL 的类型转换对索引选择的影响还真是一个不大不小的坑。

比如有这样一张 MySQL 表：

1
2
3
4
5
6
7
8
9
10

CREATE TABLE `indextest` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(10) DEFAULT NULL,
  `age` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`),
  KEY `idx_age` (`age`),
  KEY `idx_create` (`create_time`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1

MySQL 服务器设置的 binlog 单文件最大为 1GB，偶然发现会有十几 GB 大小的 binlog 文件，从产生的时间上看像是某个 cron job 使用了超大的 transaction，为了找出“罪魁祸首”，我需要分析一下 binlog。

Code swarm 是一个可视化项目，最常见的用途是把代码仓库的提交历史可视化，changesets 以时间顺序回放，每个发生变更的文件作为一个闪亮的光点从各处汇聚在对应的 committer 身上，把项目的演进历史以视频的方式形象地呈现出来，通常还会配上激动人心的背景音乐，令程序员们潸然泪下。

近来美国在尚未通过的 SOPA 法案上产生了巨大争议，该法案最邪恶的地方在于，它使得 ISP 和版权方有权利因为某网站上有一点侵权内容而“拔其网线” - 使其域名无法解析，此权利也很容易被滥用。