自从 2006年11月 ↓

新版本总是意味着新的feature，但同时也意味着新的venture.
我们目前的数据库架构为读写分开的Master(1)+Slave(2)，最近希望把版本由目前的4.1.18升级到5.0，为了稳妥起见，首先把其中一台Slave进行了升级，不久，问题就出现了，很多有unsigned属性的字段的值在Master和Slave上出现了不同。比如smallint(5) unsigned类型，Master上是0，Slave上却是65535。仔细一看，65535原来就是无符号类型的-1。测试一下，在Master上建立一个smallint(5) unsigned类型的字段，初始值为0，对它进行update操作，update test set test_unsigned=test_unsigned-1 where id=1;在Master(4.1.18)上，得到的值仍然为0，同步到Slave(5.0)上以后，值果然变成了65535。faint！
Google之，发现在MySQL5的manual中，详细的描述了MySQL4.1和MySQL5的区别，看来想全面升级到MySQL5，在操作unsigned类型字段时要十分小心，或者提前判断是否会产生小于0的值，或者使用类似下面的语句：UPDATE t SET i = CAST(i - 1 AS SIGNED);否则结果可能不是你想要的。
另我非常faint的是，在MySQL手册关于Master-Slave类型的replication的描述中，建议版本相同或者Master的版本低于Slave的版本，可是在上面的例子中，这明显有问题，或者怪我们程序判断的不严格？

不希望数据表中有重复记录的时候我们可以给表添加一个联合唯一索引
例如，user表中有user_id,user_name两个字段，如果不希望有两条一摸一样的的user_id和user_name，我们可以给user表添加两个字段的联合唯一索引：
alter table user add unique index(user_id,user_name);
这样当向表中添加相同记录的时候，会返回1062的添加失败信息。
但是有一种情况是表中已经有n个重复的记录，这时候我们才想起来要添加唯一索引，再执行上面的操作时，数据库会告诉你已经有重复的记录了，建立索引失败，这时候，我们可以用下面的操作：
alter ignore table user add unique index(user_id,user_name);
它会删除重复的记录（别怕，会保留一条），然后建立唯一索引，高效而且人性化。

由于我政府的英名决策，抓狗的风声越来越紧，小区里已经几乎看不见大狗们的身影，不得已，终于决定在周末的时候把玉米这小子送去上学了，当然主要目的还是躲躲风头。
我们周六先到学校去考察了一下，那儿是一个平房的大院，据说教练原来是训练军犬的，每只狗都有自己的3m见方的房间（所谓房间就是带盖的笼子），平时都院里晒太阳，撒欢儿，晚上”房间”里睡觉，我们去的时候院里已经有大概20多只狗，一进院子便群狗乱吠。
周日一天基本都在家陪着玉米，它还不知道要被送走，照旧傻乎乎的吃了玩，喝了睡，我们看着它心情那是相当的复杂，高兴的是可以送它去学点东西，改改原来的坏毛病，又担心别人照顾不好它，风餐露宿的，万一再被别人欺负。。。我终于能体会当年老爸老妈送我们上学时的心情～～～
周日大风降温，狂大的风，巨冷。
在车里这小子还东张西望，无知无畏的样子，到了地儿看着人家把它关起来，它还和住邻居的撒摩耶摇头摆尾，匆匆忙忙的告个别我们就闪了，临出院子的时候听见玉米在里面哼唧。。。它还从来没离开过我们。
回到家，打开厨房门居然没有东西扑上来，心里很不爽。踢到玉米平时玩的球居然没有东西跑过来，进出厨房的时候居然没有东西跑来跑去的跟着捣乱。。。统统的很不爽。不过出门的时候不用东张西望，有人敲门的时候不用东躲西藏。。也不知道平时都睡我们床头的玉米，这个大风降温的晚上睡的好不好～～～
今天媳妇就打电话过去问，人家说它能吃能睡更能疯玩儿，看来所有的担心都是多余的，这小子压根儿就不想我们，拷，回来关紧闭先。