去年八月在 OReilly 贊助的開放源碼大會上，MySQL 開發人員Monty Widenius 宣布了一項新的項目叫做MaxSQL，一個目前十分流行的MySQL 數據庫的增強版本。最重要的是MaxSQL 結合了來自Sleepycat軟件的最新的 Berkeley DB 庫，因此程序以另外一種表類型支持事務處理。
目前，你還不能直接安裝MaxSQL的二進制版本，你必須從MySQL 3.23 beta 的源碼來編譯，但是當你看到這篇文章的時候，你應該可以從MySQL 網站下載MaxSQL了。 想要自己編譯最新的版本的話，請看“編譯自己的MaxSQL”一文，在那裡我詳細敘述了編譯步驟。
什麼是事務？
為什麼增加了一個事務安全的表需要命名一個新的項目名字呢？或許我應該提一下MySQL 的主要開發者 Monty Widenius 有兩個孩子，一個叫My ，另一個叫Max，哥兒倆相互競爭不說，另外還有一個對手PostgreSQL。
關於PostgreSQL，我們本期的另外一篇文章"PostgreSQL為電子商務加了一個等級" 會有提到，是一個對我們都有利的競爭者，因為每一個項目組都在克服自己產品中的弱點。而MaxSQL 所作的就是消除這兩個對手之間的 差距。MySQL 有很快的讀操作，因此很受Web 開發者歡迎，因為Web 內容 以讀為主。但是，另外一方面，因為MySQL 使用了ISAM 表，所以寫操作時，必須給整個表加鎖，這樣減慢了更新和插入的操作，當流量很大時會是一個很大的問題。當每秒請求數目劇增時，寫操作在服務器中排隊，Web 頁面會發生超時錯誤。
使用了 MaxSQL後，你依然可以建立普通的快速ISAM 類型表，也可以在某個表需要使用事務安全特性時，選擇使用新的BDB 類型。
BDB 表在寫操作時要比 ISAM 快得多。因為他們不使用表一級的鎖。 另外，對於任何事務表的處理都有日志記錄以防硬件失效。日志允許 COMMIT/ROLLBACK 操作。例如，你在一個在線商店下訂單, 訂單會在"order" 表中記錄一行。系統會從"inventory"表中的某一行中 減掉對應的庫存貨物數量。如果使用MySQL的ISAM表，一個CGI 程序需要執行以下六步：
LOCK inventory table
LOCK order table
UPDATE inventory table
UPDATE order table
UNLOCK inventory table
UNLOCK order table
如果有人鎖住了任何一個表，這個 CGI 程序就必須等待。一旦兩個都加鎖以後，CGI 才可以更新他們，然後釋放鎖。如果在第三步失敗的話（例如服 務器宕機），order 表就不會被更新而你的庫存已經減了下來。
使用 MaxSQL BDB 事務安全類型的表之後，只需要四步：
BEGIN
UPDATE inventory table
UPDATE order table
COMMIT
你不必等待釋放鎖，所有的四個步驟是一個事務。只要讀到BEGIN 語句， MySQL 就把命令讀入緩沖，一直到看到COMMIT 命令為止。因此，所有的操作在同一時間發生。即使有意外操作發生（磁盤滿或者掉電），也不會因此而毀掉數據庫。在一個非事務安全的系統裡，如果第三步失敗的話， 數據庫就會發生不一致，而在BDB 表中，如果對order 表操作失敗MySQL 會恢復對庫存表的操作，這樣不會發生不一致的情況了。
許多網站采用早期版本的 MySQL來實現表鎖，但是采用 MaxSQL 以後，會很容易和快速。
還有什麼新式武器？
除了因為 BDB 表需要把 MySQL 轉變成 MaxSQL之外，另外還有一些 重要的改變。其中一個秘密武器就是數據庫復制，你可以把一個服務器作為 主服務器，而配置任意數目的從服務器，這樣對主服務器的更新也將拷貝到 從服務器。為了使用這樣的系統，改變你的CGI 腳本，讓他們知道MySQL 從 服務器的存在。這個腳本也會在不能連接上主服務器時，切換到從服務器。
需要注意的是，這樣的系統對很少寫操作的數據庫才有效，因為復制不是同步的。如果有人在主服務器上啟動一個事務，而在事務結束之前服務器死機的話，主服務器沒有時間把更新復制到從服務器。這樣，這種系統不合適作電子商務，而且，CGI 腳本總是首先連接主服務器，所以不是負載平衡的系統。
另外一個重大改進是 ISAM 類型表的格式。缺省的表類型現在叫作 MyISAM。 這種類型的表能處理到每個表最大2GB ，而且可以跨平台。 你可以從Linux 拷貝一個MyISAM 文件到Solaris 而不需要任何轉換。
結論：
MaxSQL 可以作為價格昂貴的商務系統的一個很優秀的替代品。很多系統不需要處理很多的事務交易，而要求安裝Oracle。而MaxSQL 提供的事務安全的表，使更新數據庫的編程工作更加輕松。
