一个故事@MySQL DBA

Vim使用简介

orczhou — Sun, 07 Mar 2010 14:35:01 +0000

        "工欲善其事,必先利其器"
                                   《论语》

写在前头：vim是Linux下最常用的编辑工具，一般认为vim是Vi IMproved（增强的vi）的缩写，很多时候我们也把vim称为vi。vi是一个上手比较难，但是一旦掌握，就能大大提高效率的工具。本文仅介绍一些Vim使用的基本概念，读者可以根据本文给出参考文献继续深入了解Vim。

1. 认识Vi

直接使用vi（或者vim）命令，有时会看到如下的内容

                 Vim is open source and freely distributable

~                       Help poor children in Uganda!
~              type  :help iccf       for information

建议用户向荷兰ICCF捐款, 用于帮助乌干达的艾滋病患者，可以通过键入命令:help iccf查看更多细节。

你可以使用如下命令开始编辑一个文本：

vi doat.txt

2. Vim中的模式

Vi和Windows下的编辑器最大的一个不同是Vi有多种模式：Normal模式，编辑模式，命令模式。使用命令(如 vi dota.txt)后，首先进入Normal模式（这个模式下，可以移动光标的位置）；如果准备开始编辑了，按下a（或者i）就可以进入编辑模式，这时，和普通的编辑器就差不多了；完成编辑希望保存并退出文本时，你可以先按Esc进入Normal模式，然后按:wq保存并退出。（还是有点点复杂的:）事实上还有Ex Select Visual等模式）

3. Vim中的一些功能

这里将罗列一些Vi的功能，本文将不详述，因为只要你知道她有这些功能，Google大神会告诉你具体操作。

语法高亮：当你编写shell代码时，高亮可以帮你发现一些明显的语法错误；录制、播放：当你在成百次的重复一些复杂的vi操作时，录制会帮你大忙；列编辑：据我知道，很多人之所以使用破解版的UE，就是因为这个；搜索、替换：这也是编辑器基本的功能。编程函数自动补齐：还在等什么，Have a try（欢迎补充）

4. ctrl+s冻结Vim的问题

刚开始使用vim的人，会习惯性地使用crtl+s保存，这将会导致Linux终端被冻结。事实上，ctrl+s会锁住Linux终端的输入和输出。可以使用crtl+q解除锁定，恢复正常。

参考手册：

sourceforge.net上的中文文档 | 滇狐大作viki | Vim the editor | 善用佳软介绍vim

Feed enhanced by Better Feed from Ozh

MySQL本版信息

orczhou — Thu, 04 Mar 2010 12:58:14 +0000

本文完全参考MySQL Manual，毫无新意。

从MySQL5.5之后，版本的信息会像这个样子：MySQL-5.5.2-m2，Why?

以前MySQL开发进程是将大量特性加入到MySQL代码库进行测试开发，然后分发5.1.0……5.1.44等版本。缺点是某个小特性（代码）的测试有可能会影响到整个版本。这也是MySQL6.0迟迟没有RC的一个原因。

现在使用“里程碑模式”(milestone mode)，而每一个milestone版本则仅关注某一小部分特性进行开发测试，这样可以让MySQL能够更快的放出对应的RC。下一个milestone则在原来（上一个milestone）基础上进行开发，仅关注某一小部分特性进行开发和测试，并对这一小部分特性进行全面、彻底的测试。

例如，MySQL 5.5.0-m2 是Milestone 2的第一个版本。该milestone专注于代码基本的稳定性。在m2发展历程中，我们还会看到MySQL 5.5.1-m2，MySQL 5.5.2-m2等。

为什么不是m1呢？（认为5.4就是m1）。

Feed enhanced by Better Feed from Ozh

Linux iostat监测IO状态

orczhou — Mon, 01 Mar 2010 05:13:28 +0000

Linux系统出现了性能问题，一般我们可以通过top、iostat、free、vmstat等命令来查看初步定位问题。其中iostat可以给我们提供丰富的IO状态数据。

1. 基本使用

$iostat -d -k 1 10

参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。

$iostat -d -k 1 10
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              39.29        21.14         1.44  441339807   29990031
sda1              0.00         0.00         0.00       1623        523
sda2              1.32         1.43         4.54   29834273   94827104
sda3              6.30         0.85        24.95   17816289  520725244
sda5              0.85         0.46         3.40    9543503   70970116
sda6              0.00         0.00         0.00        550        236
sda7              0.00         0.00         0.00        406          0
sda8              0.00         0.00         0.00        406          0
sda9              0.00         0.00         0.00        406          0
sda10            60.68        18.35        71.43  383002263 1490928140

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             327.55      5159.18       102.04       5056        100
sda1              0.00         0.00         0.00          0          0

tps：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。

kB_read/s：每秒从设备（drive expressed）读取的数据量；kB_wrtn/s：每秒向设备（drive expressed）写入的数据量；kB_read：读取的总数据量；kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes。

上面的例子中，我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是39.29，下面是各个分区的TPS。（因为是瞬间值，所以总TPS并不严格等于各个分区TPS的总和）

2. -x 参数

使用-x参数我们可以获得更多统计信息。

iostat -d -x -k 1 10
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          1.56  28.31  7.80 31.49   42.51    2.92    21.26     1.46     1.16     0.03    0.79   2.62  10.28
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          2.00  20.00 381.00  7.00 12320.00  216.00  6160.00   108.00    32.31     1.75    4.50   2.17  84.20

rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；wrqm/s：每秒这个设备相关的写入请求有多少被Merge了。

rsec/s：每秒读取的扇区数；wsec/：每秒写入的扇区数。r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；

await：每一个IO请求的处理的平均时间（单位是微秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。

%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

3. -c 参数

iostat还可以用来获取cpu部分状态值：

iostat -c 1 10
avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.98    0.00    0.35   11.45   86.22
avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.62    0.00    0.25   34.46   63.67

4. 常见用法

$iostat -d -k 1 10        #查看TPS和吞吐量信息
iostat -d -x -k 1 10      #查看设备使用率（%util）、响应时间（await）
iostat -c 1 10            #查看cpu状态

5. 实例分析

$$iostat -d -k 1 |grep sda10
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda10            60.72        18.95        71.53  395637647 1493241908
sda10           299.02      4266.67       129.41       4352        132
sda10           483.84      4589.90      4117.17       4544       4076
sda10           218.00      3360.00       100.00       3360        100
sda10           546.00      8784.00       124.00       8784        124
sda10           827.00     13232.00       136.00      13232        136

上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。

iostat -d -x -k 1
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          1.56  28.31  7.84 31.50   43.65    3.16    21.82     1.58     1.19     0.03    0.80   2.61  10.29
sda          1.98  24.75 419.80  6.93 13465.35  253.47  6732.67   126.73    32.15     2.00    4.70   2.00  85.25
sda          3.06  41.84 444.90 54.08 14204.08 2048.98  7102.04  1024.49    32.57     2.10    4.21   1.85  92.24

可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。

参考文献：

Feed enhanced by Better Feed from Ozh

乐在其中

orczhou — Sun, 28 Feb 2010 10:41:24 +0000

今天，创业九楼阅读文档，外面烟花声此起彼伏

乐在其中烟花何其寂寞

Feed enhanced by Better Feed from Ozh

Linux本地磁盘（硬盘）介绍

admin — Wed, 24 Feb 2010 12:05:27 +0000

本文试图从硬件结构、逻辑结构两方面来介绍Linux中本地磁盘的基本知识。

1. 硬件结构

一块磁盘由多个盘面组成，每个盘面有一个对应的磁头（heads），我们可以在该盘面上存储我们需要的信息。

每一个盘面，被分成多个圆环，我们称之为柱面（cylinders）。每一个柱面又被分割为多个扇形区域，简称扇区（sectors），参见下图：

（图片来源www.eygle.com/）

两个红色环形之间是一个柱面；图中黄色标记部分是一个扇区。

2. fdisk -l 查看磁盘情况

#fdisk -l
Disk /dev/sda: 73.2 GB, 73274490880 bytes
255 heads, 63 sectors/track, 8908 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          16      128488+  83  Linux
/dev/sda2              17        1928    15358140   83  Linux
/dev/sda3            1929        2189     2096482+  82  Linux swap / Solaris
/dev/sda4            2190        8908    53970367+   5  Extended
/dev/sda5            2190        2450     2096451   82  Linux swap / Solaris
/dev/sda6            2451        2711     2096451   82  Linux swap / Solaris
/dev/sda7            2712        2972     2096451   82  Linux swap / Solaris
/dev/sda8            2973        8908    47680888+  83  Linux

可以看到，上面的磁盘/dev/sda有255个磁头，8908个柱面，每个柱面轨道上有63个扇区。因为每个扇区大小为512bytes，所以总大小约为：8908 * 63 * 512 * 255 = 73270794240(和上面的73274490880 相差3696640，不知道是什么地方多出来的)。

3. 磁盘分区、文件系统、挂载点

我们继续看上面的例子，磁盘/dev/sda共分为8个分区：/dev/sda1，/dev/sda2，……，/dev/sda8，Start和End分别为各个分区的起始和结束柱面。例如分区/dev/sda2从柱面17开始到柱面1928结束，则大小约为（1928-17）* 63 * 512 * 255 = 14.6G。

可以通过df -h来查看分区/dev/sda2的挂载目录：

#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              15G   13G  1.1G  92% /
/dev/sda1             122M   20M   96M  17% /boot
tmpfs                 2.0G  669M  1.4G  33% /dev/shm
/dev/sda8              45G   26G   17G  62% /u01

可以看到，分区/dev/sda2挂载根目录 / 上。然后，通过文件/etc/fstab来查看该分区的文件系统：

#more /etc/fstab
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=/u01              /u01                    ext3    defaults        1 2
LABEL=SWAP-sda5         swap                    swap    defaults        0 0
LABEL=SWAP-sda6         swap                    swap    defaults        0 0
LABEL=SWAP-sda7         swap                    swap    defaults        0 0
LABEL=SWAP-sda3         swap                    swap    defaults        0 0

看到根目录 / 使用了Linux ext3文件系统。

至此，我们看到磁盘/dev/sda共分为八个分区。其中第二个分区/dev/sda2从柱面17到柱面1928结束，大小约为15G，该分区挂载在根目录 / 上，使用了ext3的文件系统。

4. 其他磁盘分区

在上面的fdisk -l 列表中我们一共可以看到八个磁盘分区。上面已经分析了/dev/sda2，我们再看来看看其他的分区。

在Linux中第一个分区/dev/sda1，为引导扇区，挂载在/boot上
第二个分区挂载在根目录 / 上，大小15G，为ext3文件系统
第三个分区为交换分区，从柱面1929到2189，大小约：（2189 - 1929）* 63 * 512 * 255 = 2G。
第四个分区为扩展分区，后面四个分区均是该分区的一部分。该分区从柱面2190到8908结束。
分区五、六、七为扩展分区的子分区，均为交换分区，单个大小均为2G。所以全部的交换分区大小共2G + 2G*3 = 8G。
第八个分区为扩展分区的最后一个子分区，挂载在/u01上，大小约为（8908 - 2973）* 63 * 512 * 255 = 45G。

以上为示例主机上的全部磁盘分区，以及挂载情况。

5. 小结

有了以上信息，我们就基本清楚了硬件结构以及对应的逻辑结构，需要使用的命令其实也很少：

#fdisk -l
#df -h
#more /etc/fstab

6. 补充

# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/1                /                       ext3    defaults        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
......

关于/etc/fstab的简单补充：

第一列是：一般是设备（分区），如也有是LABEL=×××的，这是ext2 ext3特有的卷标，可以通过e2label来查看各个设备的卷标。
第二列是：挂载点
第三列是：文件系统
第四列是：文件系统挂载时候的参数（例如NFS有时候需要用户名密码等）
第五列是：标志是否需要备份1为需要，0为不需要
第六列是：启动时，是否需要fsck检查磁盘1为先检查，2为后检查，0为不检查

在fstab文件还有部分第一列是none的，这些都是不需要物理磁盘的文件系统。典型的如/proc文件系统：

none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0

Feed enhanced by Better Feed from Ozh

春节感冒

orczhou — Mon, 22 Feb 2010 06:04:41 +0000

这是步入工作后的第一个春节假期，感冒是在这个的假期最后一天：

大概是喝了一点加冰的可乐，上午喉咙就有些疼了，一般这也是我感冒的征兆，但是也有很多时候，就只是喉咙痛而已，所以自己也没有太在意。我的喉咙（扁桃体）是很脆弱的，很早之前医生就建议不要和太冰或者太烫的饮料。匆忙的火车、汽车让自己暂时忘记了不适，晚上到住处洗完澡后，才发现把羽绒服裹上，身体表面发烫，但是还是觉得一阵阵冷意；隐隐的头痛也明显了；虽没有吃晚饭，却一点也不饿，也感觉自己一点胃口都没有。

晚上随便吃点东西后，像往常一样睡觉。裹着厚厚的被子，身体还是感觉到阵阵凉意，不知道从哪儿来的。

半夜醒来，真真的感冒才发威。喉咙还是和白天一样疼，感觉全身发烫，奇怪的是还觉得冷。身体姿势无论怎样调整，都无法入睡。逐渐感觉头痛得厉害，脑袋晕晕的。虽然想拼命的继续睡着，不过发现自己反而越来越清醒。窗外有微弱的灯光照到房间的天花板，盯着天花板，思绪犹如脱缰的野马到处乱跑，安静的睡着是不可能了。

身体还是继续异常，“全身烫，但是还是觉得冷”，看了很久的天花板，并没有“致知”什么。头痛又来了，隐隐的头痛犹如夏天床头一两只嗡嗡的蚊子，时断时续，但是你却无法定位它到底在哪儿。半夜，周围异常安静。慢慢感觉着自己的头痛，突然有了新的发现：我可以感觉到太阳穴部位的脉搏跳动的频率。平时需要把手放上去才能感觉到的。夜还在继续，我还是在床上翻来覆去探索能够睡着的姿势。

脑子时常浮出一句话：“健康才是最重要的”。

女友终于还是被吵醒了，摸摸我额头，惊讶到：“发烧得很厉害啊”。她立刻起床，烧了一些热水。倒了一杯温水给我喝，另外用温毛巾帮我敷了敷额头。（这都是写常用的“物理降温”方法）

过了一会儿，身体总算没那么难受了，额头的脉搏跳动也感觉不到了。不知道什么时候才又睡着。

确实，“健康才是最重要的”。

Feed enhanced by Better Feed from Ozh

InnoDB Double write

orczhou — Thu, 04 Feb 2010 04:57:17 +0000

记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。

涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。

1. 什么是Double Write

在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。

咋一看，这个过程有些多余

2. 为什么需要Double Write

InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。

试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。

举个例子：在InnoDB的log file中有如下Log：

Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020

其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。

所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。

简而言之，Double write就是为了避免Partial page writes而设计的。

3. Double Write对性能的影响

系统需要将数据写两份，一般认为，Double Write是会降低系统性能的。peter猜测可能会有5-10%的性能损失，但是因为实现了数据的一致，是值得的。Mark Callaghan认为这应该是存储层面应该解决的问题，放在数据库层面无疑是牺牲了很多性能的。

事实上，Double Write对性能影响并没有你想象（写两遍性能应该降低了50%吧？）的那么大。在BP中一次性往往会有很多的Dirty Page同时被flush，Double Write则把这些写操作，由随机写转化为了顺序写。而在Double Write的第二个阶段，因为Double Write Buffer中积累了很多Dirty Page，所以向真正的数据文件中写数据的时候，可能有很多写操作可以合并，这样有可能会降低Fsync的调用次数。

基于上面的原因，Double Write并没有想象的那么糟。另外，Dimitri在测试后，发现打开和关闭Double Write对效率的影响并不大。

4. 相关参数与状态

是否打开了double write:


root@(none) 07:16:16>show variables like "%double%";
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+

Double write的使用情况：


root@(none) 07:15:50>SHOW STATUS LIKE "%innodb_dblwr%";
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| Innodb_dblwr_pages_written | 145373349 |
| Innodb_dblwr_writes        | 2249336   |
+----------------------------+-----------+

上面可以看到，从BP共Flush了145373349个Pages到double write buffer中；一共调用了2249336次write写到真正的数据文件。可见，相当于每次write合并了 145373349 / 2249336 = 64.6次Flush。（这就是为什么double write buffer为什么并不会对效率有很大影响的原因）

5. 我的看法

在某些文件系统（ZFS等）层面能够保证不出现Partial page writes时，可以关闭Double Write。因为它对性能影响并不大，一般情况都建议打开，毕竟带来的数据安全性保障可能是我们更关心的。

参考文献：

[0]. Manual about Double Write

[1]. Innodb Double Write

[2]. Do you need the InnoDB doublewrite buffer

[3]. MySQL Performance: InnoDB Doublewrite Buffer Impact

Feed enhanced by Better Feed from Ozh

详解MyISAM Key Cache(后篇)

orczhou — Tue, 02 Feb 2010 13:56:43 +0000

在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。

Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。

1. 如何配置Key Cache的大小

#配置文件my.cnf
key_buffer_size=50*1024*1024

另外，Key Cache的大小可以动态的改变

2. 给数据表划分单独的Key Cache

例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。

SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX t1 IN hot_cache;
SET GLOBAL hot_cache.key_buffer_size=0;

3. 预先载入某些数据表的索引

LOAD INDEX INTO CACHE t1, t2

4. 关于Key Cache的使用情况观察 Flush现象


mysql> show status like "key%";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 14468    |
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 30586575 |
| Key_reads              | 157      |
| Key_write_requests     | 7100408  |
| Key_writes             | 1199800  |
+------------------------+----------+
mysql> flush tables;             （注意，请不要在业务高峰期执行）
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |   #所有修改的block都已经被flush了
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 38333936 |
| Key_reads              | 207      |
| Key_write_requests     | 8819898  |
| Key_writes             | 1255245  |
+------------------------+----------+

5. 需要注意的事项

内存中缓存的索引块（Key Cache），有时候并不会及时刷新到磁盘上，所以对于正在运行的数据表的索引文件（MYI）一般都是不完整的。如果此时拷贝或者移动这些索引文件。多半会出现索引文件损坏的情况。

可以通过Flush table命令来将Key Cache中的block都flush到磁盘上。所以，一般要动态移动MyISAM表需要执行以下步骤：

首先，刷新数据表，并锁住数据表：（注意，请不要在业务高峰期执行）

FLUSH TABLES WITH READ LOCK;

可以通过下面的命令来查看没有被Flush的索引块数量


mysql> show status like "Key_blocks_not_flushed";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |
+------------------------+----------+

最后，移动对应的文件（MYI MYD FRM）。

参考

MySQL Manual about Key cache

Update 2010-03-01:

在Why you should ignore MySQL’s key cache hit ratio中，Baron Schwartz提到很多关于Key Cache命中率的问题：一般情况，诸如“命中率”这样参数本身的意义并不明显，历史数据对比才比较靠谱（文中提到的“Key_reads/Uptime”）；关于Key_buffer_size大小，Baron Schwartz认为并没有统一的标准，而是应该具体情况具体分析，大小尽量大于你最常被访问的Key block（ “In my opinion, you should choose a key_buffer_size that is large enough to hold your working set — the index blocks that are frequently used.”）。

Feed enhanced by Better Feed from Ozh

Linux下C语言连接MySQL

orczhou — Tue, 26 Jan 2010 11:21:30 +0000

相对于Window下的设置，Linux要简单的很多。

1. 示例程序

$ vi mysql-c-api.c
#include 
#include "mysql/mysql.h"
int main(){
        MYSQL mysql;
        mysql_init(&mysql);
        mysql_options(&mysql,MYSQL_OPT_COMPRESS,0);
        mysql_options(&mysql,MYSQL_INIT_COMMAND,"SET autocommit=0");
        if (!mysql_real_connect(&mysql,"10.2.3.4","user","passwd","database",0,NULL,0))
        {
                fprintf(stderr, "Failed to connect to database: Error: %sn",
                mysql_error(&mysql));
        }
        return 0;
}

2. 编译命令

在MySQL编译后的二进制文件中，有一个很有用的二进制文件“mysql_config”（一般和mysql命令在同一个目录下），我们可以通过这个程序找到需要的头文件和连接库：

$ gcc -o a.out $(mysql_config --cflags) mysql-c-api.c $(mysql_config --libs)
$ ./a.out

Feed enhanced by Better Feed from Ozh

详解MyISAM Key Cache(中篇)

orczhou — Sun, 17 Jan 2010 10:14:46 +0000

在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。

1. 相关参数

该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold

2. 原理介绍

(1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。
(注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值)

(2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。

(3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。

(4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。

(5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。

3. 如何使用Midpoint Insertion Strategy

我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。

（未完待续）

Feed enhanced by Better Feed from Ozh