yangting

1.一手房即新房支取：采取一次性付款的员工，准备购房合同、发票、身份证，这三项的原件、复印件，及工资卡复印件(有联名卡并需办理按月提取的请提交联名卡复印件)，并到内网(实用表单)下载《住房公积金支取记录单》。

　　采取贷款或分期付款购买住房的，资料同上，如本人无购房合同原件，可用与银行签订的借款合同原件及复印件代替，同时交购房合同复印件。办理支取时，购房人是配偶一方的需持结婚证原件及复印件，并且需由购房人先行支取，并提供其支取记录单复印件。

这两天被你搞伤了，你知道否！

好文章

重做分区后，partprobe 可以帮助我们，不重启机器，而/dev/下面看到分区！

• Sending data

  The thread is reading and processing rows for a SELECT statement, and sending data to the client. Because operations occurring during this this state tend to perform large amounts of disk access (reads), it is often the longest-running state over the lifetime of a given query.

LVM1 has read-only snapshots. Read-only snapshots work by creating an exception table, which is used to keep track of which blocks have been changed. If a block is to be changed on the origin, it is first copied to the snapshot, marked as copied in the exception table, and then the new data is written to the original volume.

In LVM2, snapshots are read/write by default. Read/write snapshots work like read-only snapshots, with the additional feature that if data is written to the snapshot, that block is marked in the exception table as used, and never gets copied from the original volume. This opens up many new possibilities that were not possible with LVM1's read-only snapshots. One example is to snapshot a volume, mount the snapshot, and try an experimental program that change files on that volume. If you don't like what it did, you can unmount the snapshot, remove it, and mount the original filesystem in its place. It is also useful for creating volumes for use wit

每天都是主库切换，爽

From DBA's standpoint, you have a couple of choices for storage allocation.
- Storing all files on SSD, not using HDD at all
- Storing all files on HDD, not using SSD at all
- Using SSD and HDD altogether (some files on SSD, others on HDD).

Which is the best approach? My favorite approach is storing tables on SSD, storing Redo Log files, Binary Log files, and SYSTEM-tablespace(ibdata) on HDD. I describe a detailed reason and some DBT-2 benchmarking results below.

On HDD, there is a huge difference between random writes and sequential writes. Sequential writes is very fast on HDD with write cache. On the other hand, on SSD, there is not so much difference between random writes and sequential writes. Though performance highly depends on SSD drives themselves, you probably notice that sequential write performance is not so different between HDD and SSD (or even faster on HDD). Since HDD has a longer history and is cheaper than SSD, currently the

喜欢Mysql，不仅仅是因为他简单的使用，更深一层次的是因为他的开源、他的插入式引擎及更优秀的plugin！从队列式存储引擎Q4M(http://q4m.github.com/)到memcache 的UDF(http://hi.baidu.com/ytjwt/blog/item/5fc8303f226c542f71cf6c3c.html) 到本文要说到的NoSQL for MySQL，去年的某一天，一朋友跟我说，nosql性能有多好多好时，我说，如果提取像k/v形式的数据，假设：用主键查询一个数据，你觉得性能会怎样 呢？其实当时我也知道，肯定是比不过memcache之类的cache，因为，mysql有一系列的认证，一系列的语法、词法分析！

前段一个偶然的时间里，下载percona-server突然发现一个名叫HandlerSocket的东东，一时好奇，google一把，发现这不就是我一直想要的在mysql里实现nosql的东西吗?兴奋之余，也动手安装及使用了一把，下面把我的步骤列出来!

主要参考：http://whitesock.javaeye.com/blog/811339

1：安装

HandlerSocket老简单了，只需要5.1版本以上的s