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