MySQL

上回书 说到留言板的问题时提到留言板当时没有解决，在文内的模板中可以看到我当时是采用了一种非常对付的方法：直接将之前的评论直接作为文章内容输出出来。这导致了页面不太美观。

趁着周末我把之前 Movable Type 的数据库重新捋了一下，把其中的 2256 条留言用类似 isso迁移时的方法转换成了 json，然后就可以在 remark42 中导入了。中国有句俗话叫三搬一火，意思是搬三次家大约等于失一次火，这次留言内容搬家我也丢掉了一些东西：Remark42 的一项设计理念便是尽量不保存可以追踪用户的数据，例如用户的 E-mail 在 Remark42中只会保存一个与之对应的 SHA1，对于网站的主人来说，这意味着他们不能直接从这些保存的数据中获得用户的 E-mail 地址（当然，实际情况中，这类单向函数并不能阻止他们在知道这些信息的情况下验证某个 SHA1是不是某个 E-mail 地址，但总归这要比把数据存在数据库里安全得多），因此这个迁移过程也就意味着所有相关的明文数据消失了。除此之外，Movable Type还保存了许多类似于用户网站地址这样的信息，我在转换时考虑了一下，由于许多人的网站都已经不在了，迁移的意义不太大，因此最终决定不迁移这些数据了。

考虑到现在还在用 Movable Type 的人应该已经没有几个了，我感觉我的方法可能对其他人没有太大的参考意义，这里只是简单做个记录。代码写的比较乱，就不拿出来丢人了。

有个疑似 OCD 患者最近抽风升级了一下 MySQL 数据库，然后发现 blog 里面全都变成了乱码。

那乱码的模式一看就是把 utf8 直接扔进了 latin1 的数据库，一看 SHOW CREATE TABLE mt_entry 发现果然如此。

最近帮公司的一个客户做了一个数据库迁移，客户声称数据是 utf-8 的，然而在使用过程中出现了许多乱码，检查发现数据并非 utf-8，而是 utf-8 编码之后的 big5，而排序方式更是混乱不堪的默认的utf8-swedian-ci。

MySQL的国际化支持很差。MySQL从 4.1 版本开始大刀阔斧地进行了不兼容的改动，简单地说，这些改动让相当多的操作默认以UTF-8进行，然而这会给旧的应用程序带来很多问题。许多文献推荐使用 SET CHARACTER SET 作为 workaround，尽管这能够解决一些问题，但这种做法本质上会导致 MySQL 进行额外的转换，因此并不是十分理想。

今天早上MSN上收到的消息，Sun公司宣布收购了MySQL AB，中午又听说，Oracle收购了 BEA。今天是什么日子啊……

这年头，只会用 MySQL 的人就敢说自己懂数据库；
这年头，只写了几百行代码（还有各种恶心的bug）的人，就敢到处丢人现眼；
这年头……当然，跟以前没什么两样，如果这个世界上没有不靠谱的人，那也就没有靠谱的人了。

今天，John Birrell同学commit了一个不大不小的patchset—-将KSE变为内核选项。具体说来，在-CURRENT上，KSE不再是一个必选项了。

KSE是FreeBSD 5.0-CURRENT时的一个非常重要的技术探索，它是对由华盛顿大学THOMAS E. ANDERSON等人提出的调度器激活概念的一个实现。

对于M:N线程来说，调度器激活是一项十分先进的概念。在这个模型中，内核并不需要了解用户态线程的细节，而用户态线程也并不是由内核直接调度，相反，这些线程被绑定到一系列"调度实体"上，内核能够看到这些调度实体，并在上下文切换时激活用户态的线程调度器。由于减少了内核-用户态的上下文切换操作，因此理论上这一模型能够获得更好的性能。

最近 current 邮件列表讨论的很凶的一个问题是，MySQL很不理性地在每一个I/O操作时都调一次time()。这一操作在FreeBSD上面相当的昂贵(为了保证精度)，而Linux采取了许多优化(有些是牺牲精度的)措施，因而性能差距越来越大。

于是有一个人在FreeBSD上做了试验，说改一下默认的时钟能够将性能提高6倍……不带这么玩的，ft……

BTW. clive也测了一下，在他机器上结果是：

Good news is that the University has remembered to pay for a project, bad news are, I am looking for a person who is capable for maintaining Unix(R) Systems like FreeBSD and Linux, Solaris, and is knowledgable in scripting languages, etc (PHP, MySQL, etc) for the company I am working for, etc. Please let me know by sending your resume to delphij at delphij dot net.

另一个部门的同事说他们那里的 mysql 总是会在凌晨0:00-1:00这段时间发生诡异的问题，即CPU占用迅速升高，并停止响应。

重起mysql无效，但到1:00之后，只要重起mysql，就可以恢复正常。

为此，今天我做了一次非常冒险的在线调试工作，并最终解决了问题。

The answer is not so trivial. You must migrate everything, from MT’s configuration to its databases, etc. In addition, proper permission must be set in order to get it run.