建立新資料表：CREATE TABLE new_table LIKE old_db.old_table;

複製資料：INSERT new_table SELECT * FROM old_db.old_table;

收工。

記得用 root 執行以下指令

sudo su


切到放原始碼的目錄下

cd /usr/src/


先取回 MySQL Server 原始碼

apt-get source mysql-server-5.1


目前版本是 5.1-5.1.49

cd mysql-5.1-5.1.49/


將所有 patch 加入

dpatch apply-all


回到原本目錄

cd -


拿回 HandlerSocket 原始碼，如果沒有 get 可以先安裝 apt-get install git-core

git clone https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL.git handlersocket


產生 Makefile

cd handlersocket/
sh autogen.sh
./configure --with-mysql-source=../mysql-5.1-5.1.49/ --with-mysql-bindir=/usr/bin/ --with-mysql-plugindir=/usr/lib/mysql/plugin/


安裝到系統中 (/usr/lib/mysql/plugin/)

make
make install


到 MySQL 中安裝 handlersocket.so

mysql -u root -p -h localhost

mysql> install plugin handlersocket soname 'handlersocket.so';
Query OK, 0 rows affected (0.02 sec)


接著建立 MySQL 的設定檔

touch /etc/mysql/conf.d/handlersocket.cnf


設定檔內容

[mysqld]
loose_handlersocket_port = 9998
# the port number to bind to (for read requests)
loose_handlersocket_port_wr = 9999
# the port number to bind to (for write requests)
loose_handlersocket_threads = 16
# the number of worker threads (for read requests)
loose_handlersocket_threads_wr = 1
# the number of worker threads (for write requests)
open_files_limit = 65535
# to allow handlersocket accept many concurrent
# connections, make open_files_limit as large as
# possible.

修改 services

vi /etc/services


加入兩個服務

mysql-hsr 9998/tcp # the port number to bind to (for read requests)
mysql-hsw 9999/tcp # the port number to bind to (for write requests)

然後重新啟動 MySQL ，到這邊 Server 的 Plugin 就安裝完成了

/etc/init.d/mysql restart


接著安裝 Client 端程式，這邊以 PHP 為例，安裝 php-handlersocket

下載 tarball

wget http://php-handlersocket.googlecode.com/files/php-handlersocket-0.0.7.tar.gz


解開，並且安裝

tar -zxvf php-handlersocket-0.0.7.tar.gz
cd php-handlersocket/
phpize
./configure
make
make install


然後新增設定檔加入模組

touch /etc/php5/conf.d/handlersocket.ini


裡面加入

;php-handlersocket
extension=handlersocket.so

這樣就差不多完成了，下一篇文章會簡介使用方法。

圖中大幅降低的值是 MySQL Server Status 的 Questions ，這個值的定義是 MySQL 執行過的 SQL 敘述次數，這個數據的定義可以看： 5.1.6. Server Status Variables#statvar_Questions。

也可以看到 open table / file 次數也降低一半

Open_tables 表示 被開啟的資料表數目 (The number of tables that are open.)， Opened_files 則是被 MySQL 內部函數 my_open() 打開的檔案個數，這兩個數據的定義可以看： 5.1.6. Server Status Variables#statvar_Open_tables。

• Handler_read_rnd_next (82K) 過大，解法：當進行大量排序查詢的時候不理想，或許可以調高 read_buffer_size 。
• Handler_read_rnd (32G) 過大，描述：表示每次 query 都必須要直接掃整個 table 而且 index 可能沒有發揮作用，但是我不曉得是不是 Active Record 造成的，因為我 WHERE 和 ORDER BY 選用的欄位都有檢查過了，應該都建了 index
• Qcache_lowmem_prunes (40K) 描述：我應該要把 query cache 調小，因為每次查出來結果都不同(鮮少重複的查詢)，所以不需要調太大。
• Created_tmp_disk_tables (1,725 ) 過大，在磁碟上建立的臨時 table 太大，應該要調高 tmp_table_size 的數值(記憶體中建立臨時 table )，以改善效能。
• Sort_merge_passes (24) 過大，應該要增加 sort_buffer 的值。
• Opened_tables (2639) 過大，則要增加 table_cache 的值。
• Table_locks_waited (112K) 過大，雖然我的 Table_locks_immediate 有 12M，而 Table_locks_waited 有 112K ，發生鎖定等待的情況大約是比例上為 1/100 (一百次鎖定中，可以直接鎖定 99 次，有一次要等待)

今天在 Matt Yonkovit 的 Big DBA Head 看到了他提出 MySQL 設定檔的範例 ( MySQL 本身也都會附上不同環境的設定例範，我的機器之前是以 my-huge.cnf 作為參考設定。)：

64 bit system – 假設 64 bit CPU 以及作業系統
8GB+ of memory – 超過 8 GB 記憶體
Dedicated DB Box – 專職的資料庫伺服器
All MyISAM – 使用 MyISAM 儲存引擎
[mysqld]
thread_cache_size = 256
table_cache = 1024
key_buffer = 4000M
sort_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
max_allowed_packet = 1M
tmp_table_size=64M
max_heap_table_size=64M
query_cache_size=128M
myisam_recover = backup
myisam_sort_buffer_size=512M
skip-innodb

參考網址：5 Minute DBA MyISAM Example Config Files

備註：Big DBA Head 的作者是 Matt Yonkovit ，之前是昇陽下面 MySQL 的資深顧問，有 11 年 Oracle 的經驗、9 年的 MySQL 的經驗、以及 8 年的 SQL Server 經驗。

$sql = "SELECT `url_id`, count( url_id ) FROM `url_detail_history` GROUP BY `url_id` HAVING count(id) > 1499;";
$result = mysql_query($sql);

$i = 0;
while (list($url_id, $count) = mysql_fetch_row($result) )
{
    echo "id = $url_id and, count =$count <br />";

    /* 掃描資料表，先反向排序，再用 LIMIT 來取得第 1500 筆資料，這筆資料的 ID 就是臨界值 - 重點 - */
    $sql2 = "SELECT `id` FROM `url_detail_history` WHERE `url_id` = $url_id ORDER BY `id` DESC LIMIT 1499,1500";
    $result2 = mysql_query($sql2);

    $row = mysql_fetch_array($result2);
    $critical = $row['id'];
    echo "critical: $critical";

    /* 比臨界值小的都刪掉 */
    $sql3 = "DELETE FROM `url_detail_history` WHERE `url_id` = $url_id and `id` < $critical";
    mysql_query($sql3);

    echo "<br />";
    $i++;
}
echo "<hr /> total = $i;"
/* 假設資料保留 1500 筆資料 */

這個方法一解下去，一秒不到就弄好了，資料庫頓時少了 60 MB 的資料。不過我還是想知道，有沒有辦法用純 SQL 來解(感覺上難度不低)。

(最佳的解法應該是用 Store Procedure 存到 MySQL 內，這樣它就會自己 Maintain 數目在 1500 筆，但這方面我並不是很熟悉。)

    url_detail_history 資料表
    +--------------+---------------------+------+
    | Field        | Type                | Null |
    +--------------+---------------------+------+
    | id           | bigint(11) unsigned | NO   |  -> 有 Auto_increment
    | url_id       | int(11)             | NO   |
    | visitor_ip   | varchar(15)         | NO   |
    | visitor_fqdn | varchar(100)        | NO   |
    | visitor_time | timestamp           | NO   |  -> CURRENT_TIMESTAMP
    +--------------+---------------------+------+

現在裡面有許多筆資料，可以用

SELECT COUNT(id), url_id FROM url_detail_history GROUP BY url_id

得知每個 url_id 有幾筆資料。

我前幾天寫錯了一個地方，導致資料表裡面長了大概一百萬筆資料。由於我 SQL 很弱，所以想知道有沒有辦法直接用 SQL 語法執行刪除，條件是：每個 url_id 只要總數超過 N 筆資料就刪除到只剩下 N 筆為止， 當然， id 越大代表資料越新，必須能從小的 id 開始刪起。

我有寫一段程式來跑但是效能不彰，系統 loading 飆到 100 多，拉牛上樹慘不忍睹..(以下是虛擬碼)

/* 先取出符合條件的資料 */

SELECT count(id), url_id FROM url_detail_history GROUP BY url_id HAVING count(id) > 1500

用此法個別取出 $url_id ，然後

foreach( $url_id ) {
     do {
            $id= SELECT min(id) FROM table WHERE url_id = $url_id
            DELETE FROM table WHERE id = $id
            $count = "SELECT COUNT(id), url_id FROM url_detail_history WHERE url_id = $url_id
        } while( $count < 1501)
}

這樣作法效能很差，不想這麼暴力解這個問題…

MySQL 有提供 IF 的功能，
用法： IF (bool,value1,value2)
解釋：當第一個參數為真時，回傳 value1，否則傳回 value2

可以改寫成：

SELECT
IF(`REPLY_TIME` > `TIME`, `REPLY_TIME`, `TIME`) AS `TEMPTIME`, `ID`, `POST_TITLE`, `POST_CONTET`
-- 這邊是其他欄位，而 TEMPTIME 則是產生的新欄位。
FROM `forum`
WHERE 條件子句
ORDER BY `TEMPTIME` DESC;
LIMIT 0, 資料筆數

重要的筆記…

然後複製資料庫資料 cp -R -p /var/lib/mysql /data/mysql 可是當我下指令 /etc/init.d/mysql restart 的時候，卻發現錯誤，我也找不出問題在哪(權限對了，路徑也對了，檔案也都在)。後來才發現原來 Ubuntu 還有另一個地方的設定必須要修改，就是 apparmor ：先修改 /etc/apparmor.d/usr.sbin.mysqld 這個設定檔，找出裡面原本指向 /var/lib/mysql 的目錄，全部改為新目錄。

然後重啟動就可以了！
/etc/init.d/apparmor restart
/etc/init.d/mysql restart

-- Login to MySQL
debian:# mysql -u root -pPASSWORD

-- Create a utf8 encode database.
CREATE DATABASE DB_NAME DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

-- Use the utf8 connection collation
SET NAMES utf8;

-- Import a utf8 SQL file.
SOURCE filename-utf8.sql

-- or, after create the database, back to system, and use the "mysql" command.
debian:# mysql DB_NAME -u root -pPASSWORD < filename-utf8.sql --default-character-set=utf8

in other way, we also can set my.cnf

[client]
    default-character-set=utf8
[mysqld]
    default-character-set=utf8
    default-collation=utf8_general_ci

這篇文章主要討論 Memory, MyIASM, InnoDB 三種儲存引擎，因為我只選用這三種。首先，先看個我做了很久的表格吧！

對於 MyIASM 來說，最大的好處是成本低，而且可以 create views ，這是其他儲存引擎辦不到的，但缺點就是鎖定層級以 table 為單位，而且不支援 transaction ，這些地方輸給 InnoDB 。不過 InnoDB 也是有缺點像是不支援 FULLTEXT 的索引，且記憶體佔用多、磁碟空間耗用大…等等。

我找到一篇文章針對 MyIASM, InnoDB 和 Falcon 來做比較，在這裡面 MyIASM和 InnoDB 表現都沒有差很多，唯獨在測 READ_PK_RANGE 和 READ_KEY_POINT 時候， MyIASM 爛掉了(不過主角其實是 Falcon 因為它被打趴了)。原因是：There MyISAM shows bad scalability with increasing count of thread. I think the reason is pread system call MyISAM uses to access data and retrieving from OS cache is not scaled.
InnoDB vs MyISAM vs Falcon benchmarks – part 1

而 Memory 儲存引擎的最大優點就是快、快、很快、不會對硬碟頻繁讀寫、並且用 HASH 雜湊索引(但不曉得有沒有 Btree 二元樹索引)！另外它有個特性，就是會在硬碟建立一個 .frm 檔，目的是為了存資料表的 scheme ，但是每一筆 record 還是儲存在記憶體中，這也意味著如果斷電或是關機，資料就會消失不見。

實際應用：

假設我有兩個不同類型的 Table ，分別儲存 App Data 和 Session ，我有大量連線，從伺服器上的紀錄看來，開機半天左右，總共處理近九百萬個連線(這是實際數據)。

而 App Data 的資料表作用和 Session 資料表個作用分別如下：

每個 App 啟動時，都會有一個 Session ID，而每筆 Session 都被當成一筆 Record Insert 到 Table 中做紀錄，當 Session 起始/結束的時候，才把更新的資料寫到 App Data 中。

對於 Session 個資料表的處理，我採用 Memory 為儲存引擎，因為 Session 掉了並不可惜，但卻可以換來極佳的效率，而 App Data 的資料表，我則是採用 InnoDB ，雖然相較於 MyIASM 會花上更多的 Cost 而且效率較差，但是他提供很好的鎖定(以row為單位)以及安全的復原機制，另外也支援外來鍵的設定。

推薦閱讀文章：
MySQL Storage Engine Architecture, Part 3: Details and Comparison
13.4. The MEMORY (HEAP) Storage Engine
MySQL Storage Engines

通常我喜歡用 phpMyAdmin 來倒出資料庫和還原，但是如果語系(編碼)沒設定好，那在 phpMyAdmin 裡面不管怎麼弄都會變成亂碼。這時候我們可以靠 mysqldump 指令來解決。

語法如下：

mysqldump -u USERNAME -pPASSWORD [DBname] > [filepath/filename.sql]

注意，-p後面緊接著密碼，不需要空格，其餘進階用法請 man mysqldump 。如果有編碼混亂的情況，可以先試著用：

mysqldump -u USERNAME -pPASSWORD --default-character-set=latin1 [DBname] > [filepath/filename.sql]

把資料倒出來看看，再用文字編輯器(Notepad++)開啟，如果沒有變成亂碼的話，即可把

CREATE TABLE `table` (
略
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

的 latin1 都取代為 utf8 ，請且重新儲存為 utf8 編碼的檔案(無BOM)，這樣就是一個 utf8 的完整 dump 檔了！

除了修改資料庫的連線問題之外，也可以修改 my.cnf

[mysqld]
default-character-set=utf8

[client]
default-character-set=utf8
init_connect='SET NAMES utf8'

其中[mysqld]的設定內容修改為 utf8 ，可以把資料庫預設的編碼從 latin1 改為 utf8 ，至於 client 的內容則是預設的查詢條件。要不要改就看個人意願了(我個人偏好不做修改，而是從程式那邊的查詢下手)。

舉例而言，稍據規模的專案，幾乎都有 DB 的 Driver 可找，通常 Driver 內都有一個部份在做 prefetch ，在該區加入

mysql_query("SET NAMES 'UTF8'");

這樣感覺就好多了！出來的文字編碼也不會錯了！當然，如果以後要再用 mysqldump 備份的話，記得指令要打完整

mysqldump -u USERNAME =pPASSWORD --default-character-set=utf8 [DBname] > [filepath/filename.sql]

以防倒出來的編碼不小心又錯了。

roga@Lab3:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              229G   62G  168G  27% /
tmpfs                 507M     0  507M   0% /lib/init/rw
udev                   10M   44K   10M   1% /dev
tmpfs                 507M     0  507M   0% /dev/shm
roga@Lab3:~$

我明明硬碟上什麼都沒放，怎麼會活生生被吃掉 62G 呢！？

用指令 root@Lab3:/# du -ckhs /* 一層一層慢慢查才發現原來 /var/log/mysql 裡面有一大堆 mysql-bin.0000XX ，原來這些都是 MySQL 的 Binary Log ，讓你在 MySQL 爛掉的時候可以用 Binary Log 救回來。由於我都直接 dump 每日備份，所以這個 Replay 用的 Binary Log 當然這就用不到啦！上網找了方法，只要在 my.cnf 裡面找到以下兩行設定：

expire_logs_days = 10
max_binlog_size = 100M

把 size 和保留天數調整一下就可以了。之後重新啟動 MySQL 即可見效，如果試了很多次 MySQL 都再起不能的話，直接把 /var/log/mysql 裡面的 binary 檔都移掉，這樣就可以正常重新啟動了。

注意：執行這個作法之前，請確定資料庫備份方案足夠完善，以免哪天 crash 沒有東西可以備份還原。