1. 周六坐了四小时公车去参加表哥的婚礼,这婚可真不是一般人能结的! 这么多的时间、金钱，两个字： 麻烦. 闲话不多说,祝表哥和嫂子新婚愉快,生个大胖小子,但千万别比我胖.
2. 在家族里LD属于吃饱闲着的人，大大小小的琐事都不让我插手(小时候积累的名声实在不好)， 于是想起张学友的《很想和你去吹吹风》， 跑到钱塘江边，吹了一个下午的海风。
3. 海风不是吹着玩得, 结果我现在感冒了,生不如死; 喘口气都难. 睡了一下午，难受噢~~~
4. 抽屉里有本医保的本子，需要市民卡才能用， 2个月前就通知我去做，LD就是懒， 现在后悔了吧。
表哥要结婚了，不明白为什么要这么早结束自己无忧无虑的单身贵族的生活,还是我不明白其中的责任?!?!
关于结婚,不久之前与自己从小玩到大的哥们很狠地摔在上面,忧郁 彷徨;
聪哥说人生的后50年完全是20~30岁时决定的,不置可否,然必有其道理.
还没到26,不远了,那时候我在做些什么???
在 MERGE存储引擎的简单测试 – MySQL邯郸学步 一文中,有一个Union SELECT, 极其消耗时间, 仔细分析会发现,使用的搜索条件对应字段是TIMESTAMP, 索引几乎没用. 那么我们能不能绕开时间字段,使用作为主键的自增字段object_id 呢? 就单纯示例上这种情况,是可以的. 请看下面的存储过程:
大多数时候,LD都看似很闲,所以看书也无目的性。最近看关于MySQL的东西，碰到MERGE这个存储引擎，做个小测试。
我其实只想知道一样东西，用UNION就可以合并两个查询，视图也能合并两张表数据，那么MERGE在合并表的数据后是否提供优化？
LD使用的MySQL是ArchLinux软件库中的，版本5.1.39, 配置文件默认，不做任何内存参数优化(因为使用的数据是真实的，而实际服务器上，运维也使用默认设置);
这两个表2个月前因为表字段的不同，执行一个union all的select语句要 260s 之久; 经过一番优化，已经缩短为2~3s, 但随着数据的增长，执行时间也在增加。LD一直在找解决方案，这么少的数据，还没达到100W，如果不能从SQL优化角度着手，只能从Linux系统和MySQL服务的配置想办法了。 废话不多说，Let’s Go。
