幹壞事是進步最大的原動力
在 MySQL 中，如果你有 VARCHAR(255) 這種欄位，不要對直接對這個欄位下 INDEX。因為 key 會以最大長度 255 chars 為固定大小，而非動態決定 (latin1 的時候 1 char 是 1 byte，utf8 是 3 bytes，utf8mb4 是 4 bytes)，當資料有 1M row data 就直接吃掉 1MB/3MB/4MB 的空間。
解決方法是利用「index 可以指定只取前面 n chars」這個功能來做，至於 n 要取多少就是要估算了... 在「Optimal index size for variable text in MySQL」這篇把要怎麼做的過程寫得還蠻完整的。
同樣的道理也可以用在固定寬度的 BINARY(16) 系列上。
MySQL 5.5 之前的版本只支援 Unicode 3.0 (1999 年 9 月發表)，但自從 MySQL 5.5 版開始支援 Unicode 5.0 (2006 年 7 月發表)，對於常用的 utf8 encoding 就有一些變化要注意...
參考維基百科上對 Unicode 版本的說明：「Unicode#Versions」，以及 MySQL 5.5 的文件：「MySQL :: MySQL 5.5 Reference Manual :: 10.1.10 Unicode Support」。
在 MySQL 5.5 之前，UTF-8 的設計最多吃 3bytes，因為 1byte 有 128 種組合 (7bits)，2bytes 有 2048 種組合 (11bits)，3bytes 有 65536 種組合 (16bits)，共 67712 個空間可以用，但 Unicode 3.0 只用掉 49259 個。
而從 MySQL 5.5 開始支援的 Unicode 5.0 需要 99089 個空間，所以需要用到 4bytes 的版本，也就是增加 4bytes 的 2097152 種組合 (21bits)，共 2164864 個空間。
但為了相容性，MySQL 5.5 的 utf8 encoding 還是使用 Unicode 3.0 版本。只有當特別指定 utf8mb4 encoding 時才會用到 Unicode 5.0 版本。使用 utf8mb4 encoding 時，要注意 client 端也要支援，不然會讀不到東西...
今天看到 t1.micro 也可以開 MySQL RDS 了：「Amazon RDS MySQL Now Starting at Just $19 a Month」。
拿來堆資料應該還不賴？只要 24 小時可以塞完一天的份，而且不會影響到 t1.micro 的 EBS I/O 就可以用？:p
長野雅廣的「MySQL Beginners Talk で LT してきました」這篇 slide 對不熟悉 MySQL 的人講了兩個幾乎不會錯的觀念：
先討論後面這點，算是任何 database 都通用的法則：當你遇到效能問題時，監控機制可以提供毛線球的線頭，讓你知道慢在哪裡：什麼時間滿載 (於是可以猜測是 cron job 造成，或是對應 MRTG 圖時知道是一般使用者造成的流量造成)，另外可以知道瓶頸是在 CPU (是單顆 CPU 滿載，還是整台機器都被吃滿)，I/O (是讀取滿載，還是寫入造成滿載)，或是網路。
前面這點解釋成「如果你不知道你在做什麼，就用 InnoDB Plugin 吧」，對於初學者 (slide 的標題)，就簡化成「既然你是初學者，你就用 InnoDB Plugin 吧」。原因是：
slide 不長，但這兩個重點還蠻重要的...
把主機的 MySQL 從 5.1 升級到 5.5 後，想把主機上的 MyISAM table 都換成 InnoDB。
基本上是參考「Quick tip: how to convert tables to InnoDB」這篇提到的工具以及說明。
文章裡所提到的 mk-find 是 2008 年的時候的名稱，當時這隻工具是在 Maatkit 裡面，而 2012 年則已經併入 Percona Toolkit，所以文章裡本來是 mk-find 的地方要改成 pt-find。
另外我不想嘗試把 mysql.* 改成 InnoDB (我不知道會不會爆炸)，所以我的做法是只用 --print，然後丟到 vim 裡面加上 ALTER TABLE 以及 ENGINE=InnoDB ROW_FORMAT=COMPRESSED;。
pt-find 這個指令看起來可以用在很多地方，之後應該會有不少用到的機會...
前幾天讓人吃驚的新聞，Galera Cluster 離第一次 Percona alpha 測試 (Percona Server 5.1 with Galera replication) 才九個月就進入 GA 了 (相當於九個月內就過完 Beta + RC 階段)：「Announcement of Percona XtraDB Cluster 5.5.20 GA release」。
大家最大的問題還是「這能用嗎」... 不過既然進入 GA 狀態，加上是 Percona，好像可以期待？
在 Hacker News 上看到的長期計畫，要廢除 ext/mysql：「deprecating ext/mysql」。
主要的原因是 security 習慣問題。因為 ext/mysql 不支援 prepare 與 execute 這類不需要自己處理 escape 的函式，所以使用 ext/mysql 的人必須自己處理 escape 的問題，也就是透過 mysql_escape_string 或是 mysql_real_escape_string。而很多書籍為了讓初學者容易了解，會給出很糟的範例，像是：
mysql_query("SELECT * FROM `user` WHERE `username` = '$username';");
而 $username 沒有先檢查過。
依照提議，目前只會在文件上建議改用 PDO 或是 mysqli，不會對目前版本有任何改變。接下來是 5.5 與 6.0 時會看情況決定要不要加上 E_DEPRECATED。
目前的提議還沒有提到何時要拔掉 ext/mysql，不過看起來 6.0 之前應該是不會做...
前幾天 jnlin 在 OSDC.TW 2011 上面講了「HandlerSocket – A NoSQL Plugin for MySQL」，剛好 Percona 的 Ryan Lowe 也提到了「What’s up with HandlerSocket?」，試著分析 (並猜測) HandlerSocket 為什麼沒有被廣泛使用。
除了技術的問題外，最主要在於運作：Open Source 不是把程式丟出來就覺得沒事了，要僅可能讓使用者容易使用。
比較好運作方式是在重大的 bug 修掉之後就推出 minor version release，一方面讓一些願意整合的單位有「基準」可以整合 (像是 Percona 這樣的公司)，另外一方面可以讓 community 感覺是個有在動的 project...
像是文章裡提到的兩個 bug，一個在今年年初已經修正 (write invalidate)，另外一個大約兩個禮拜前修正了 (insert auto-increment)，只是很多人不太清楚而已。
目前這個專案的感覺跟 Facebook 丟出來的 memcached 還蠻像的：「facebook / memcached」，Facebook memcached 的情況是很明顯「老闆說要 open source，我就丟出來吧」的感覺，原來的 community 也懶的理他，看一看有沒有可以用的 code 可以整合，然後繼續發展自己的...
Percona 的 Baron Schwartz 在 AWS RDS 能提供最大台的 database (68GB memory + 26 ECUs) 上測試 insert 的效能：「MySQL on Amazon RDS part 1: insert performance」
數字是 Per Minute，換算成常用的 Per Second 要記得除以 60。大約是 4k~5k 40k~50k queries/sec 的數量。這個效能不知道能不能算「好」...
雖然現在跑到台東玩，不過還是趁著在民宿休息的時候來寫一些東西好了...
剛剛看到 Pinboard 寫了一篇關於去年 12 月時 Yahoo! 內部簡報被流出時 (參考去年寫的「Yahoo! 要關閉 Delicious」) 所帶來的流量，以及對他們的影響：「Anatomy of a Crushing」。
裡面包括了架構，兩台 DigitalOne 的 server 當作主力，以及一台 ServerBeach 的 server 當作 slave (看起來是順便當作異地備份以及一些雜物服務)：
另外也提到了 MySQL 的 varchar index 的老問題...