提示：在安裝任何新版本的軟件之前，最好備份一下你的數據。盡管mysql已經最大限度的保證高質量服務，但當你使用軟件的測試發布版本時，你還是應該采取備份的方式來保護你的數據。大體來說，在從MySQL從4.1升級到5.0時，你需要做得主要包括以下幾個步驟：
•這部分主要檢查稍後建立起的修改列表裡的表項，目的是為了查找其中是否存在會影響你的應用程序的表項。這裡具體要注意哪些標志著Incompatible change的選項；這些會造成與MySQL早期版本不匹配，並且應該在更新之前引起你的注意。
•閱讀MySQL 5.0的歷史進程，理解你在5.0中能夠使用的重要的新特征。可以參閱Section D.1, “Changes in release 5.0.x (Production)”
•如果你是在Windows下運行Mysql 服務器，請參閱Section 2.3.15, “Upgrading MySQL on Windows”部分。同時你也應該注意到Windows下的MySQL服務器中有兩個是重新命名的，具體可以參閱Section 2.3.9, “Selecting a MySQL Server type”
•MySQL 5.0增加了對於存儲信息的程序的支持。該項支持需要在你的MySQL數據庫中的proc數據表。為了生成該文件，你應該運行MySQL_fix_privilege_tables腳本，有關該腳本的描述，請參閱Section 2.10.3, “Upgrading the Grant Tables”。
•MySQL5.0添加了浏覽功能。該項支持需要在MySQL數據庫中的user和db表格中添加額外的特殊權限列。為了生成這些列，你應該運行MySQL_fix_privilege_tables腳本，具體的描述見Section 2.10.3, “Upgrading the Grant Tables”.
•如果你使用復制功能，請參閱Section 6.6, “Upgrading a Replication Setup”，該部分主要提供了升級你的復制設置的相關信息。 幾個可視化行為已經在MySQL 4.1和MySQL5.0之間被改變，目的是為了保證MySQL和標准SQL的兼容性。這些改變有可能影響你的應用程序。 下面的列項主要描述了有可能影響應用程序的變化，因此你應該在將MySQL更新到版本5.0之前特別注意這些列項。
幾個變化：
•不兼容變化：對於InnoDB和MyISAM表格的TEXT列中的末端空間的索引順序改變了。從版本5.0.3開始，TEXT索引被看作是末尾的填補空間部分(如同MySQL的數據類型中的char、VARCHAR和TEXT域)。如果你在文本列中有一個索引，那麼你應該在其上運行CHECK TABLE命令。如果該檢查報錯，則需重建索引:如果是一個InnoDB表格，則清除並重新裝載該表格，如果它是個MyISAM表格則運行OPTIMIZE TABLE 或者 REPAIR TABLE命令。
•不兼容變化：含有DECIMAL 列的MyISAM 和InnoDB表格將會在升級到MySQL 5.0.6後出現損壞。在更新之前，要先將這些表格采用mysqldump進行清除，同時在更新之後重新裝載它們。(當在MySQL5.0.6中生成的這些表格在較低版本如MySQL 5.0.3到 5.0.5中使用時，同樣的不匹配情況會發生)
•不兼容變化：對於MySQL 5.0.3，服務器默認不再加載用戶定義的函數除非它們除了主函數符號外至少還有一個輔助標記(例如，xxx_init或者xxx_deinit符號)。該行為可以被--allow-suspicious-udfs選項所忽略。可參閱Section 25.2.3.6, “User-Defined Function Security Precautions”.
•不兼容變化：在MySQL 5.0中更新日志將會被刪除掉。如果你事先把它激活的話，你實際上激活的是二進制日志。
•不兼容變化：對於ISAM存儲機制的支持已經被刪除掉。如果你有任何的ISAM表格，你應該在更新之前對其進行轉換。例如將一個ISAM表格轉化成使用MyISAM存儲機制，可使用以下的聲明實現：
ALTER TABLE tbl_name ENGINE = MyISAM; 你數據庫中的其他ISAM表格的處理與此相同。
•不兼容變化：在MySQL 5.0中，對於MyISAM表格的RAID選項的支持已被刪除。如果你有使用這些選項的表格，你應該在更新之前對其進行轉換。一種方法是采取MySQLdump命令清除這些表格，編輯dump文件以刪除在CREATE TABLE聲明中RAID選項，同時重新加載dump文件。
另一種方法是使用CREATE TABLE new_tbl ... SELECT raid_tbl聲明來制造一個新的RAID表格。然而，該聲明中的CREATE TABLE部分必須含有足夠的信息來重新生成列和索引的屬性，否則列和索引的屬性有可能丟失，而不會出現在新表格當中。可參閱Section 13.1.5, “CREATE TABLE Syntax”。
•在一個具體的數據庫中，對於RAID表格的.MYD文件存儲在數據庫目錄下，而該目錄是在名字含有兩個16進制位(即00至ff)數值的子目錄中的。在對所有使用RAID選項的表格進行轉換後，這些RAID-相關的子目錄可能依然存在但是是可以被刪除的。在證明他們確實是空的之後，可以手工將他們刪除。(如果它們非空的話，則說明有一些RAID表格尚未被轉換)。
•在MySQL 5.0.6中，存儲例程和觸發器的二進制日志已經發生了變化。這個變化主要涉及到安全，復制，數據恢復，有關這方面的討論請見Section 18.4, “Binary Logging of Stored Routines and Triggers”. 。
SQL 的變化：
•不兼容變化：在MySQL 5.0.10對於觸發器的命名空間已經改變。以前的版本中，每個表格中，觸發器的名字是唯一的。現在對於schema(數據庫)必須是唯一的。這種改變的潛在原因是DROP TRIGGER語法現在使用schema名字而不是表格名(schema在可忽略的情況下是被選擇的，即當前的schema將會被使用)。當從以前的版本MySQL 5更新到MySQL5.0.10或者更新的版本時，你必須刪除所有的觸發器並且重新生成他們，否則的話，在更新之後，DROP TRIGGER將不會起作用。為了實現這個目的，我們特別提供了以下參考步驟：
1 將MySQL版本升級至5.0.10以能夠訪問INFORMATION_SCHEMA.TRIGGERS表格中的觸發器信息(它應該對於5.0.10以前版本的觸發器同樣有效。)
2 使用下面的SELECT聲明來刪除所有的觸發器定義
SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION , ' ON ', t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
INTO OUTFILE '/tmp/triggers.sql'
FROM INFORMATION_SCHEMA.TRIGGERS AS t;
該聲明使用INTO OUTFILE，所以你必須擁有FILE權限。該文件將會被在服務器主機上生成；可以根據你的喜好，來選擇一個不同的文件名。為了絕對的安全，檢查triggers.sql文件中的觸發器定義，如果必要的話，對該文件進行一下備份。
１停止服務器同時通過刪除你數據庫目錄中所有的.TRG文件來刪除所有的觸發器。改變當前路徑到你數據庫的目錄下，同時輸入命令如下： shell> rm */*.TRG
２啟動服務器，同時使用triggers.sql文件重新生成所有的觸發器。在本例子當中，命令如下：
1.mysql> delimiter // ;
2.MySQL> source /tmp/triggers.sql //
３使用SHOW TRIGGERS聲明來檢查是否所有的觸發器成功生成。
•不兼容變化：對於MySQL 5.0.15, CHAR()函數返回一個二進制字符串而不是一套連接字符集中的字符串。而一個可供選擇的USING charset語句句有可能被用來生成一個具體的字符集。同時，比256字符長的變量有可能被用來生成一
您正在看的MySQL教程是:MySQL升級：從4.1到5.0。個單一的字符集。這些改變有可能造成不匹配。
o CHAR(ORD('A')) = 'a' is no longer true:
oMySQL> SELECT CHAR(ORD('A')) = 'a';
o+----------------------+
o| CHAR(ORD('A')) = 'a' |
o+----------------------+
o| 0 |
o+----------------------+
為了進行比較，你可以通過增加一個USING語句或者對結果進行轉化在非二進制字符集中生成一個結果字符串。
MySQL> SELEC CHAR(ORD('A') USING latin1) = 'a';
+----------
-------------------------+
| CHAR(ORD('A') USING latin1) = 'a' |
+-----------------------------------+
| 1 |
+-----------------------------------+
MySQL> SELECT CONVERT(CHAR(ORD('A')) USING latin1) = 'a';
+--------------------------------------------+
| CONVERT(CHAR(ORD('A')) USING latin1) = 'a' |
+--------------------------------------------+
| 1 |
+--------------------------------------------+
oCREATE TABLE … SELECT CHAR(…)生成了VARBINARY列而不是VARCHAR列。為了生成VARCHAR列，使用USING 或者 CONVERT()來將CHAR()轉換成如同剛才描述的非二進制字符集。
o在以前的版本中，下面的聲明將0x00410041('AA'作為ucs2字符串)插入到表格中,而對於MySQL 5.0.15，聲明采取0x414值來插入一個ucs2字符。
oCREATE TABLE t (ucs2_column CHAR(2) CHARACTER SET ucs2);
oINSERT INTO t VALUES (CHAR(0x41,0x41));
•不兼容變化:從MySQL 5.0.12開始，自然連接和使用USING命令的連接包括外部連接變量，通過SQL:2003標准來進行處理的。這個改變包括對NATURAL和使用USING語句的連接去除多余的輸出列，同時規范輸出列表的次序。現在逗號操作符的優先級仍然低於JOIN。
•小數點數列以一種更為有效的格式進行存儲。為了將一個表格轉換為使用新的DECIMAL(浮點數)類型，你應該在它上面執行一個ALTER TABLE命令。ALTER TABLE命令也改變了表格的VARCHAR列以能夠使用新的VARCHAR列類型。對於和原有的應用程序可能不匹配的信息，可查閱Chapter 22, Precision Math
•MySQL 5.0.3及更高的版本在計算點數值時使用數字精度集(64位浮點數)同時回繞精確的數字。可參見Chapter 22, Precision Math
•對於MySQL 5.0.3，結尾空間將不再被從VARCHAR和VARBINARY列中移除，在MySQL 5.0.3和後續版本，對於VARCHAR 和VARBINARY列的最大長度是65,535字符和65,535字節。
注意:如果你在MySQL 5.0.3或者後續版本中，你生成了含有新的VARCHAR或者r VARBINARY列的表，那這些表格將在低於MySQL 5.0.3版本中不起作用。在降級之前將這些表格清除掉，同時在降級之後對其進行重載。
•對於MySQL 5.0.3，BIT是一個單獨的數據類型，而不是TINYINT(1)的同義。可參閱Section 11.1.1, “OvervIEw of Numeric Types”
•MySQL 5.0.2添加了幾個用於更加嚴格控制丟棄含有不合法或者丟失數值的記錄。可參閱Section 5.3.2, “The Server SQL Mode”. 和Section 1.8.6.2, “Constraints on Invalid Data”。如果你想激活這項控制但同時繼續使用存儲的不正確日期，例如'2004-02-31'，你應該采取--sql_mode=TRADITIONAL,ALLOW_INVALID_DATES啟動服務器。
•對於MySQL 5.0.2，SCHEMA和SCHEMAS關鍵字被分別當作DATABASE和DATABASES同義字所接受。(然而“schemata”是語法正確的，同時有可能出現在MySQL 5.0的系統數據庫和數據表格名字中，因此它能夠被作為一個輸出的關鍵字使用)
•在MySQL 5.0，用戶變量是不區分大小寫的。在MySQL 4.1中，SET @x = 0; SET @X = 1; SELECT @x;生成兩個變量同時返回0.而在MySQL 5.0，該命令生成一個變量同時返回1.
•一個名字為innodb_table_locks啟動選擇項被添加了進來，該選項可能導致LOCK TABLE同時也需要InnoDB表格鎖。該選項默認是被激活的。
這有可能導致使用AUTOCOMMIT=1和 LOCK TABLES的應用程序死鎖。如果你的應用程序在升級之後遇到死鎖的情況，你可能需要添加innodb_table_locks=0到你的my.cnf文件。
C API 改變:
• 因為MySQL 5.0服務器有對小數類型的數據有一種新的執行功能，如果該服務器被一些仍由MySQL4.1版本的客戶程序庫鏈接而成的老版本客戶程序所使用，就會出現一個問題，如果一個客戶使用二進制客戶機程序／服務器協議來執行准備好的能產生數值結果的聲明，就會出現錯誤提示：錯誤發生的原因是4.1版本客戶程序庫並不支持在5.0版本中增加的新MYSQL_TYPE_NEWDECIMAL類型。而服務器這端，卻沒有屏蔽這種新的小數數據類型的途徑。你可以通過和來自MySQL 5.0的客戶端庫的應用程序進行重鏈接來避免這個問題。
• MYSQL結構中的再連接標志可以通過mysql_real_connect()設置為0。而只有那些在進行MySQL_real_connect()以後沒有明確的把標志設為0或1的客戶端程序才會發生變化。默認情況下自動重新連接是被認為是危險的（主要是由於表格鎖，臨時表格，用戶變量以及會話變量在重新連接後有可能被丟失）。
