要想訂購本節所介紹的郵件列表或取消訂購，請訪問http://lists.mysql.com/。對于大多數郵件列表，可選擇能夠獲取單獨消息的正規列表版本，或選擇按天發布的包含大量消息的文摘版本。

不要將訂購信息或取消訂購的信息發送到郵件列表，原因在于，這類消息將自動分發給數千位其他用戶。

在你的所在地，可能有很多MySQL郵件列表的訂戶。如果是這樣，該地點可能會有本地郵件列表，這樣，從lists.mysql.com發出的消息將被傳播到本地列表。在這類情形下，請與你的系統管理員聯系，添加或刪除本地MySQL列表。

如果希望將郵件列表的信息傳送到郵件程序的郵箱中，請根據消息標題設置過濾器。可以使用列表ID： 或投遞至： 識別列表消息的標題。

MySQL列表包含：

·???????? 通告

該列表用于通告新的MySQL版本和相關程序。這是1種低容量列表，所有的MySQL用戶均應訂購它。

·???????? mysql

這是關于一般MySQL討論的主要列表。請注意，對于某些主題來說，在更專門的列表中會得到更好地討論。如果將問題張貼到了錯誤的列表，可能不會得到回答。

·???????? 缺陷

該列表面向那些希望隨時了解自上次MySQL版本發布以來已通報事宜的人員，或希望積極參與缺陷尋找和更正進程的人員。請參見1.7.1.3節，“如何通報缺陷和問題”。

·???????? 內部構件

該列表面向那些與MySQL代碼打交道的人員。它也是討論MySQL開發并張貼補丁的論壇。

·???????? mysqldoc

該列表面向那些與MySQL文檔打交道的人員： MySQL AB公司的人員，譯者，以及其他社區成員。

·???????? 基準

該列表面向任何對性能事宜感興趣的人員。討論主要集中在數據庫性能方面（不限于MySQL），也包括更廣的類別，如內核性能、文件系統、磁盤系統等。

·???????? packagers（包裝程序）

該列表主要討論包裝和分發MySQL方面的問題。這是供分發版維護人員交流MySQL打包事宜的論壇，為的是確保在所有支持的平臺和操作系統上，MySQL的外觀和感覺盡可能類似。

·???????? java

該列表主要討論MySQL服務器和Java方面的問題。它主要討論JDBC驅動程序，包括MySQL Connector/J。

·???????? win32

該列表涵蓋了在Microsoft操作系統環境下（如Windows 9x, Me, NT, 2000, XP和2003）與MySQL軟件有關的所有主題，

·???????? myodbc

該列表涵蓋了與使用ODBC連接到MySQL服務器有關的所有主題。

·???????? gui-tools

該列表涵蓋了與MySQL GUI工具有關的所有主題，包括MySQL管理員以及MySQL控制中心圖形客戶端。

·???????? cluster

該列表主要討論MySQL簇。

·???????? dotnet

該列表主要討論MySQL服務器和.NET平臺方面的問題。它與MySQL Connector/Net提供人的關系最密切。

·???????? plusplus

該列表涵蓋了使用C++ API進行MySQL編程的所有主題。

·???????? perl

該列表涵蓋了與Perl對MySQL支持、以及DBD::mysql有關的所有主題。

如果無法從MySQL郵件列表或論壇獲得問題解答，一種選擇是購買MySQL AB的支持服務。這樣，你就能與MySQL開發人員直接聯系。

下面介紹了一些英語以外其他語言的MySQL郵件列表。這些郵件列表不是由MySQL AB運營的。

·???????? <mysql-france-subscribe@yahoogroups.com>

法語郵件列表。

·???????? <list@tinc.net>

朝鮮語郵件列表。發送電子郵件訂購mysql your@email.address。

·???????? <mysql-de-request@lists.4t2.com>

德語郵件列表。發送電子郵件訂購mysql-de your@email.address。在http://www.4t2.com/mysql/站點上，可找到關于該郵件列表的更多信息。

·???????? <mysql-br-request@listas.linkway.com.br>

葡萄牙語郵件列表。發送電子郵件訂購mysql-br your@email.address。

·???????? <mysql-alta@elistas.net>

西班牙語郵件列表。發送電子郵件訂購mysql your@email.address。

通報缺陷的正常地址是http://bugs.mysql.com/，它也是我方缺陷數據庫的地址。這是1個公共數據庫，任何人都能瀏覽它并進行相應的搜索。如果登錄到系統，可輸入新的報告。

編寫良好的缺陷報告需要耐心，但在第1時間正確地完成它不僅能節省我們的時間，也能節省你自己的時間。良好的缺陷報告應包含對缺陷的完整測試情況，以便我們能夠在下個版本中更正該缺陷。本節介紹的內容用于幫助你正確地編寫報告，從避免將你的時間浪費在對我們幫助不大或沒有幫助的事上，

我們鼓勵任何人使用mysqlbug腳本來生成缺陷報告（或通報問題）。Mysqlbug可在腳本目錄下找到（源碼分發版），也能在MySQL安裝目錄的bin子目錄下找到（二進制分發版）。如果不能使用mysqlbug（例如，如果你正在Windows平臺上運行），應包括本節所述的所有必要信息（更重要的是，應介紹操作系統和MySQL版本），這點十分重要。

通過自動確定下述信息，mysqlbug腳本能夠幫助你生成報告，但是，如果遺漏了某些重要事項，請將其包含在消息中。請認真閱讀本節，并確保在你的報告中包含了本節所述的所有信息。

在張貼問題前，最好使用MySQL服務器的最新生產版或開發版對問題進行測試。通過在所含的測試范例上使用“mysql test < script_file”，或運行缺陷報告中所含的Shell或Perl腳本，任何人均應能重復該缺陷。

對于在缺陷數據庫（http://bugs.mysql.com/）中張貼的所有缺陷，均會被納入或記錄在下一個MySQL版本中。如果只需要少量更改就能更正問題，我們或許會給出更正該問題的補丁。

如果發現MySQL中存在敏感的安全缺陷，請發送電子郵件至security@mysql.com。

如果有1份可重復的缺陷報告，請將其提交到缺陷數據庫，http://bugs.mysql.com/。注意，即使在該情況下，也應首先運行mysqlbug腳本以找出與你的系統有關的信息，這是一個不錯的習慣。對于任何我們能再現的缺陷，在下一個MySQL版本中修正它的機會很大。

要想通報其他問題，請使用MySQL郵件列表。

請注意，我們可能會對包含過多信息的消息做出響應，但不太會對包含過少信息的消息做出回應。人們常會省略掉一些事實，因為他們認為自己知道了故障的原因，并想當然地認為這類細節無關緊要。良好的原則是： 如果你對陳述某事猶豫不定，請陳述之。如果我們要求你提供初始報告中缺少的信息，在報告中編寫多行信息源比等候回復要快，麻煩也更小。

在缺陷報告中，最常犯的錯誤包括：（a）未包含所使用MySQL的版本號，以及（b）未完全描述安裝了MySQL服務器的平臺（包括平臺類型，以及版本號）。這是高度相關的信息，如果沒有它，99％的缺陷報告無用。我們遇到這類問題，“為何它對我沒用”？ 隨后，我們發現在該MySQL版本中，所請求的特性尚未實施，或在較新的MySQL版本中已更正了報告中描述的缺陷。有些時候，錯誤與平臺相關，在這類情況下，如果不知道操作系統和平臺的版本號，我們幾乎不可能更正任何問題。

如果你是從源碼編譯MySQL的，如果與問題有關，還應提供有關編譯器的信息。問題經常出在編譯器，但人們卻認為問題與MySQL有關。大多數編譯均處于不斷的開發過程中，并會變得越來越好。為了確定問題是否與你的編譯器有關，我們需要知道你所使用的編譯器。注意，所有的編譯問題均應被當作缺陷并予以通報。

在你的報告中包含良好的問題描述時，報告最有幫助。也就是說，應給出示例，指明導致問題的所有事項，并準確描述問題本身。最好的報告應包含完整的示例，這類示例應闡明再現缺陷或問題的方式。請參見E.1.6節，“如果出現表崩潰，請生成測試案例”。

如果程序產生了錯誤消息，也應將其包含在你的報告中，這點很重要。如果我們打算使用程序搜索檔案，最好是通報的錯誤消息與程序生成的錯誤消息準確匹配。（即使是字母的大小寫也應考慮在內）。永遠不要嘗試從記憶中再現錯誤消息，而是應將整個消息拷貝并粘貼到報告中。

如果遇到與Connector/ODBC (MyODBC)有關的問題，請生成1份跟蹤文件，并與報告一起發送給我們。請參見26.1.1.9節，“如何通報MyODBC問題或缺陷”。

請記住，很多閱讀你報告的人員會使用80列的顯示器。使用mysql命令行工具生成報告或示例時，如果輸出內容可能會超過這類顯示器的可用寬度，應使用“--vertical”選項（或“\G”語句終結符），例如EXPLAIN SELECT語句，請參見本節后面給出的示例。

請在你的報告中包含下述信息：

·???????? 你所使用的MySQL分發版的版本號（例如MySQL 4.0.12）。通過執行mysqladmin version，即可了解正在運行版本。Mysqladmin程序位于MySQL安裝目錄的bin子目錄下。

·???????? 出現問題的機器的制造商和型號。

·???????? 操作系統的名稱和版本。如果你使用的是Windows操作系統，通常能通過雙擊“我的電腦”圖標并點擊“幫助/關于Windows”菜單來了解操作系統的名稱和版本。對于大多數Unix操作系統，可通過執行命令uname –a獲取這類信息。

·???????? 某些時候，內存容量（實際內存和虛擬內存）也有關系。如果懷疑它，也應包含這類數值。

·???????? 如果你正在使用的是MySQL軟件的源碼分發版，還須提供所使用編譯器的名稱和版本。如果使用的是二進制分發版，需要提供其名稱。

·???????? 如果在編譯過程中出現問題，應給出準確的錯誤消息，出錯文件中的不良代碼，以及該代碼附近的數行內容。

·???????? 如果mysqld停止運行，還應通報導致mysqld崩潰的查詢。通常，能夠通過運行啟用了查詢日志功能的mysqld找出它，然后在mysqld崩潰后查找日志。請參見E.1.5節，“使用日志文件找出mysqld中的錯誤原因”。

·???????? 如果數據庫表與問題有關，還應包含mysqldump --no-data db_nametbl_name的輸出。這是一種了解數據庫中表相關信息的簡單易行而且功能強大的方式。該信息能幫助我們建立與你所遇到的情況相匹配的場景。

·???????? 對于與SELECT語句的速度有關的缺陷或問題，總應包含“EXPLAIN SELECT ...”的輸出，以及SELECT語句生成的行數（至少）。對于每個涉及的表，應包含SHOW CREATE TABLE tbl_name的輸出。你所提供的關于具體情況的信息越多，得到幫助的可能性就越大。

下面給出了一個良好缺陷報告的示例。應使用mysqlbug腳本張貼它。本例采用了mysql命令行工具。對于輸出內容可能會超過80列顯示器可用寬度的語句，應使用“\G”語句終結符。

mysql> SHOW VARIABLES;

mysql> SHOW COLUMNS FROM ...\G

?????? <output from SHOW COLUMNS>

mysql> EXPLAIN SELECT ...\G

?????? <output from EXPLAIN>

mysql> FLUSH STATUS;

mysql> SELECT ...;

?????? <A short version of the output from SELECT,

?????? including the time taken to run the query>

mysql> SHOW STATUS;

?????? <output from SHOW STATUS>

·???????? 如果在運行mysqld時出現錯誤或問題，應提供導致異常的輸入腳本。該腳本應包含任何所需的源文件。越能再現具體情況的腳本越好。如果能夠創建可再現的測試范例，請將其張貼到http://bugs.mysql.com/，它將得到優先對待。

如果你不能提供腳本，至少應在你的郵件中包含mysqladmin variables extended-status processlist的輸出，以提供關于系統執行情況的某些信息。

·???????? 如果不能生成包含數行內容的測試范例，或者如果測試表過大以至于無法發送到郵件列表（超過10行），應使用mysqldump轉儲表，并創建描述問題的README文件。

使用tar和gzip或zip創建文件的壓縮包檔案，并使用FTP將檔案傳輸到ftp://ftp.mysql.com/pub/mysql/upload/。然后將問題提交到我們的缺陷數據庫中，http://bugs.mysql.com/。

·???????? 如果你認為MySQL服務器生成了奇怪的查詢結果，不僅應包含結果，還應給出你對該結果的看法，以及支持觀點的基礎。

·???????? 提供問題的示例時，最好使用實際情況下已有的變量名、表名等，而不是新名稱。問題可能與變量名或表名有關。或許這類情況很罕見，但安全總比道歉強。歸根結底，對你來說，提供關于實際情況的示例要簡單些，當然對我們也更好。如果你的數據不打算展示給其他人，請使用FTP將其傳輸到ftp://ftp.mysql.com/pub/mysql/upload/。如果信息是高度保密的，而且你甚至不打算向我們展示，請使用其他名稱給出示例，但請注意，這應是最后的選擇。

·???????? 如果可能，應包含相關程序的所有選項。例如，應指明啟動mysqld服務器時使用的選項，以及用來運行MySQL客戶端程序的選項。對于程序（如mysqld和mysql）選項以及configure腳本的選項，通常是解答問題的關鍵，關系十分密切。包含它們總不是壞主意。如果使用了任何模塊，如Perl或PHP等，還應給出它們的版本。

·???????? 如果你的問題與權限系統有關，請給出mysqlaccess的輸出，mysqladmin reload的輸出，以及進行連接時獲得的所有錯誤消息。測試權限時，首先應運行mysqlaccess。接下來，執行mysqladmin reload version，并與導致問題的程序相連。mysqlaccess可在MySQL安裝目錄的bin子目錄下找到。

·???????? 如果你有關于某一缺陷的補丁，也請將它包含在內。但不要認為該補丁是我們所需的全部，如果未提供補丁所更正缺陷的必要信息（如測試范例），不要假定我們會使用它。我們可能會通過補丁發現問題，或者不能理解該補丁，如果是這樣，我們不會使用該補丁。

如果我們不能準確核實補丁的目的，將不會使用它。測試范例會對我們有所幫助。請指明該補丁能處理所有的問題。如果我們發現補丁不能工作的臨界情況（即使很罕見），它可能是無用的。

·???????? 關于缺陷是什么、出現原因、以及缺陷導因的猜測通常是錯的。即使是MySQL團隊，在未使用調試器判定缺陷真實原因的情況下，也不能妄加猜測。

·???????? 請在你的缺陷報告中指明，你已參閱了參考手冊并寄出了檔案，以便讓其他人知道你已作了自行解決問題的嘗試。

·???????? 如果遇到解析錯誤，請仔細檢查語法。如果不能找出錯誤出現在那里，很可能是因為你使用的MySQL服務器版本不支持你使用的語法。如果你使用的是http://dev.mysql.com/doc/上提供的當前版本和手冊，不要包含你所使用的語法，MySQL服務器不支持你的查詢。在這種情況下，唯一的選擇是自行實施語法，或發送電子郵件至<licensing@mysql.com>，并尋求實施方案。

如果手冊中涵蓋了你所使用的語法，但你使用的是舊版本MySQL服務器，請檢查MySQL變更史，以查看語法的實施時間。在這種情況下，可以選擇升級到較新的MySQL服務器版本。請參見附錄D：MySQL變更史。

·???????? 如果問題在于數據崩潰，或訪問特殊表時出錯，首先應使用CHECK TABLE和REPAIR TABLE或myisamchk進行檢查并嘗試修復。請參見第5章：數據庫管理。

如果你使用的操作系統是Windows，請使用SHOW VARIABLES LIKE 'lower_case_table_names'命令核實“lower_case_table_names”的值。

·???????? 如果經常獲得崩潰的表，請嘗試找出發生的時間和原因。在這種情況下，MySQL數據目錄下的錯誤日志可能會包含關于它的一些信息。（這是名稱中包含.err后綴的文件）。請參見5.11.1節，“錯誤日志”。在你的缺陷報告中，請包含該文件提供的相關信息。如果在更新期間，未殺死更新進程，正常情況下，mysqld不會造成表損壞。如果你能夠找到mysqld停止的原因，我們會更容易地為你提供更正它的補丁。請參見A.1節，“如何確定導致問題的原因”。

·???????? 如果可能，請下載并安裝最新版本的MySQL服務器，并檢查你的問題是否得到解決。所有版本的MySQL軟件均經過徹底測試，并應能無故障運行。我們致力于盡可能地向后兼容，你也應能夠毫不困難地在不同的MySQL版本間進行切換。請參見2.1.2節，“選擇要安裝的MySQL分發版”。

如果你是享受支持服務的客戶，請將缺陷報告交叉張貼在mysql-support@mysql.com，以獲得更高的優先級，并將其張貼到恰當的郵件列表，以查看是否有人遇到了類似問題（或解決了問題）。

關于通報MyODBC中存在缺陷的更多信息，請參見26.1.1.9節，“如何通報MyODBC問題或缺陷”。

關于某些常見問題的解決方案，請參見附錄A：問題和常見錯誤。

將答案單獨發送給你而不是發送到郵件列表時，良好的禮節是，對回答進行歸納總結并將結果發送到郵件列表，以便其他人也能從你所收到、并解決了問題的回應中受益。

MySQL 4.1支持子查詢和導出表。“子查詢”指的是嵌套在另一語句中的SELECT語句。“導出表”（未命名視圖）是另一語句的FROM子句中的子查詢。請參見13.2.8節，“Subquery語法”。

從MySQL 4.1版起，可以使用聯合或其他方法重寫大多數子查詢。關于如何完成該任務的更多信息，請參見13.2.8.11節，“對于較早的MySQL版本，采用聯合方法重寫子查詢”。

MySQL服務器不支持Sybase SQL擴展： SELECT ... INTO TABLE ....。但MySQL服務器支持標準的SQL語法INSERT INTO ... SELECT ...，它基本上相同。請參見13.2.4.1節，“INSERT ... SELECT語法”。

INSERT INTO tbl_temp2 (fld_id)

??? SELECT tbl_temp1.fld_order_id

??? FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

作為備選方式，可以使用SELECT INTO OUTFILE ...或CREATE TABLE ... SELECT。

從5.0版開始，MySQL支持SELECT ... INTO，以及用戶變量。在使用光標和局部變量的存儲程序中也可以使用相同的語法。請參見20.2.9.3節，“SELECT ... INTO語句”。

MySQL服務器（3.23至該系列的最高版本，所有4.0版本，以及更高版本）支持采用InnoDB和BDB事務存儲引擎的事務。InnoDB提供了全面的ACID兼容性。請參見第15章：存儲引擎和表類型。

MySQL服務器中的其他非事務性存儲引擎（如MyISAM）遵從不同的數據完整性范例，稱之為“原子操作”。按照事務術語，MyISAM表總能高效地工作在AUTOCOMMIT=1模式下。原子操作通常能提供可比較的完整性以及更好的性能。

由于MySQL服務器支持兩種范例，因而你能決定是否利用原子操作的速度更好地服務于你的應用程序，或使用事務特性。該選擇可按表進行。

正如所闡述的那樣，事務性和非事務性表類型之間的權衡主要取決于性能。事務性表對內存和磁盤空間的要求更高，CPU開銷也更大。另一方面，多種事務性表類型，如InnoDB，也能提供很多顯著特性。MySQL服務器的模塊化設計允許同時使用不同的存儲引擎，以滿足不同的要求，并在所有情形下，提供最佳性能。

但是，即便使用非事務性MyISAM表，你將如何使用MySQL服務器的特性來保持嚴格的完整性呢？這些特性與事務性表類型相比又如何呢？

1.??? 如果應用程序采用了特定的編寫方式，依賴于在關鍵情況下能夠調用ROLLBACK而不是COMMIT，那么事務性類型更方便。使用事務，還能確保未完成的更新或崩潰的活動不被提交到數據庫，能為服務器提供自動回滾的機會，并保存你的數據庫。

如果使用非事務性表，MySQL服務器幾乎在所有情況下均允許你解決潛在的問題，方式是在更新前進行簡單檢查，并運行檢查數據庫一致性的簡單腳本，如果出現不一致性，該腳本能自動修復它或給出告警。注意，僅使用MySQL日志或增加額外日志，通常能完美地更正表，同時不會造成數據完整性損失。

2.??? 在很多情況下，能夠對關鍵的事務更新進行重寫，使之成為“原子”類型。一般而言，所有由事務解決的完整性問題均能用LOCK TABLES或原子更新解決，從而確保了服務器不會自動中斷，后者是事務性數據庫系統的常見問題。

3.??? 為了安全使用MySQL服務器，無論是否使用事務性表，僅需啟用備份和二進制日志功能。這樣，你就能解決使用其他事務性數據庫系統時遇到的任何問題。無論使用的數據庫系統是什么，啟用備份總是個好主意。

事務范型有自己的優點和不足之處。很多用戶和應用程序開發人員喜歡這類簡單性，在出現問題時或必要時，通過代碼解決問題。但是，即使你是原子操作范型的新手，或更熟悉事務，也請考慮非事務性表的速度益處，與經過優化調整的最快的事務性表相比，它的速度快3～5倍。

在完整性具有最高重要性的情況下，即使是對非事務性表，MySQL也能提供事務級別的可靠性和安全性。如果使用LOCK TABLES鎖定了表，所有更新均將被暫時中止直至完整性檢查完成。如果你獲得了對某一表的READ LOCAL鎖定（與寫鎖定相對），該表允許在表尾執行并行插入，當其他客戶端執行插入操作時，允許執行讀操作。新插入的記錄不會被有讀鎖定屬性的客戶端看到，直至解除了該鎖定為止。使用INSERT DELAYED，能夠將插入項置于本地隊列中，直至鎖定解除，不會讓客戶端等待插入完成。請參見13.2.4.2節，“INSERT DELAYED語法”。

從我們賦與其名稱的意義上，“原子”絕非不可思議的。它僅意味著，你能確信在每個特性更新運行的同時，其他用戶不能干涉它，而且不會出現自動回滾（如果你不小心，對于事務性表，這種情況可能發生）。MySQL服務器還能保證不存在臟讀。

下面列出了使用非事務性表的一些技術：

·???????? 對于需要事務的循環，通常能使用LOCK TABLES進行編碼，不需要光標來更新正在處理的記錄。

·???????? 要想避免使用ROLLBACK，可采取下述策略：

1.??? 使用LOCK TABLES鎖定所有希望訪問的表。

2.??? 執行更新前，測試必須為真的條件。

3.??? 如果一切正常，執行更新。

4.??? 使用UNLOCK TABLES解除鎖定。

與使用具有回滾可能性的事務性表相比，它通常具有更快的速度，雖然并非始終如此。該解決方案唯一不能處理的情形是，在更新中途殺死了線程。在這種情況下，將釋放所有鎖定，但某些更新可能尚未執行。

·???????? 也可以使用函數在單一操作中更新記錄。采用下述技術，能獲得效率很高的應用程序。

o??????? 根據其當前值更改列。

o??????? 僅更新出現實際變化的列。

例如，當我們更新某些客戶信息時，僅更新已更改的客戶數據，與原始行相比，僅測試已更改的數據或依賴于已更改數據的數據是否未出現變化。對于已更改數據的測試，它是通過UPDATE語句的WHERE子句完成的。如果記錄未更新，將向客戶端發出消息： “一些你改變的數據已被其他用戶更改”。接下來，我們在窗口中給出了舊行和新行，以便用戶決定使用哪個版本。

這給出了與列鎖定類似的結果，但效果更好，使用相對于其當前值的值，僅更新了某些列。這意味著，典型的UPDATE語句與下面給出的類似：

UPDATE tablename SET pay_back=pay_back+125;

?

UPDATE customer

? SET

??? customer_date='current_date',

??? address='new address',

??? phone='new phone',

??? money_owed_to_us=money_owed_to_us-125

? WHERE

??? customer_id=id AND address='old address' AND phone='old phone';

它很有效，即使其他客戶端更改了pay_back或money_owed_to_us列中的值，也能使用。

·???????? 在很多情況下，用戶希望將LOCK TABLES和／或ROLLBACK用于管理唯一ID。可以在不使用鎖定功能或回滾的情況下，使用AUTO_INCREMENT列以及LAST_INSERT_ID() SQL函數或mysql_insert_id() C API函數，更有效地處理之。請參見12.9.3節，“信息函數”。請參見25.2.3.36節，“mysql_insert_id()”。

我們通常能使用代碼來處理行級鎖定方面的需求。在某些情況下，實際上不需要它，InnoDB表支持行級鎖定。通過MyISAM表，能夠在表中使用標志列，并完成類似下面的操作：

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

如果找到行，而且原始行中的row_flag不是1，對于受影響的行數，MySQL返回1。

你可以認為MySQL將前述查詢更改為：

UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

對于MySQL，在5.0版本中實現了存儲程序。請參見第20章：存儲程序和函數。

從5.0.2版開始，在MySQL中實現了基本的觸發器功能，計劃在MySQL 5.1中進一步發展它。請參見第21章：觸發程序。

在MySQL服務器3.23.44和更高版本中，InnoDB存儲引擎支持對外鍵約束的檢查功能，這些約束包括CASCADE、ON DELETE和ON UPDATE。請參見15.2.6.4節，“FOREIGN KEY約束”。

對于InnoDB之外的其他存儲引擎，MySQL服務器能夠解析CREATE TABLE語句中的FOREIGN KEY語法，但不能使用或保存它。未來將進行擴展，能夠將這類信息保存到表規范文件中，以便能被mysqldump和ODBC檢索。稍后，還將為MyISAM表實現外鍵約束。

外鍵增強為數據庫開發人員提供了多項益處：

·???????? 假定關聯設計恰當，外鍵約束使得程序員更難將不一致性引入數據庫。

·???????? 數據庫服務器具有集中式約束檢查功能，因而沒有必要在應用程序一側執行這類檢查。這樣，就消除了不同應用程序使用不同方式檢查約束的可能性。

·???????? 使用級聯更新和刪除，簡化了應用程序代碼。

·???????? 設計恰當的外鍵有助于以文檔方式記錄表間的關系。

請記住，這些好處是以數據庫服務器為執行必要檢查而需的額外開銷為代價的。服務器額外檢查會影響性能，對于某些應用程序，該特性不受歡迎，應盡量避免。（出于該原因，在一些主要的商業應用程序中，在應用程序級別上實施了外鍵邏輯）。

MySQL允許數據庫開發人員選擇要使用的方法。如果你不需要外鍵，并希望避免與強制引用完整性有關的開銷，可選擇另一種表類型取而代之，如MyISAM。（例如，MyISAM存儲引擎為僅執行INSERT和SELECT操作的應用程序提供了極快的性能，這是因為插入能和檢索同時進行）。請參見7.3.2節，“表鎖定事宜”。

如果你不打算利用引用完整性檢查具備的優點，請記住下述要點：

·???????? 不存在服務器端外鍵關聯檢查時，應用程序本身必須處理這類關聯事宜。例如，將行按恰當順序插入表時應謹慎，并應避免產生孤立的子記錄。必須能夠在多記錄插入操作期間更正出現的錯誤。

·???????? 如果ON DELETE是應用程序所需的唯一引用完整性功能，請注意，從MySQL服務器4.0起，可以使用多表DELETE語句，用單一語句從多個表中刪除行。請參見13.2.1節，“DELETE語法”。

·???????? 從具有外鍵的表刪除記錄時，在缺少ON DELETE的情況下，一種解決方式是為應用程序增加恰當的DELETE語句。實際上，它與使用外鍵同樣快，而且移植性更好。

注意，使用外鍵在某些情況下會導致問題。

·???????? 外鍵支持能處理很多引用完整性事宜，但仍需要仔細設計鍵的關系，以避免循環規則或不正確的級聯刪除組合。

·???????? DBA需要創建關聯拓撲，這會使從備份中恢復單獨表變得困難，該類情形并不罕見。（加載依賴其他表的表時，MySQL允許你臨時禁止外鍵檢查，從而降低了該難度）。請參見15.2.6.4節，“FOREIGN KEY約束”。在MySQL 4.1.1以前。重新加載時，mysqldump能夠生成自動利用該性能的轉儲文件。

注意，SQL中的外鍵用于檢查和強制引用完整性，而不是聯合表。如果打算用SELECT語句獲取多個表的結果，可在表之間執行聯合操作：

SELECT * FROM t1, t2 WHERE t1.id = t2.id;

請參見13.2.7.1節，“JOIN語法”。請參見3.6.6節，“使用外鍵”。

ODBC應用程序常使用不帶“ON DELETE ...”的FOREIGN KEY語法來生成自動WHERE子句。

在MySQL服務器5.0版中實現了視圖功能（包括可更新視圖）。在5.0.1和更高版本中，提供了二進制版的視圖功能。請參見第22章：視圖。

View（視圖）十分有用，它允許用戶像單個表那樣訪問一組關系（表），而且僅允許對它們的這類訪問。視圖也能限制對行的訪問（特定表的子集）。對于列控制的訪問，可使用MySQL服務器中的高級權限系統。請參見5.7節，“MySQL訪問權限系統”。

在設計視圖的過程中，我們的宏偉目標是，在SQL的范圍內盡可能與關聯數據庫系統的“Codd's Rule #6”兼容。“所有理論上可更新的視圖，實際上也應是可更新的”。

一些其他SQL數據庫采用“--”作為注釋開始標志。MySQL服務器采用“#”作為注釋起始字符。對于MySQL服務器，也能使用C風格的注釋：/*該處為注釋*/。請參見9.5節，“注釋語法”。

MySQL服務器3.23.3和更高版本支持“--”注釋風格，但要求注釋后面跟1空格（或控制字符，如新行）。之所以要求使用空格，是為了防止與自動生成SQL查詢有關的問題，它采用了類似下面的代碼，其中，自動為“!payment!”插入“payment”的值：

UPDATE account SET credit=credit-!payment!

考慮一下，如果“payment”的值為負數如“-1”時會出現什么情況：

UPDATE account SET credit=credit--1

在SQL中“credit--1”是合法的表達式，但是，如果“--1”被解釋為注釋開始，部分表達式將被舍棄。其結果是，表達式的意義與預期的意義完全不同。

UPDATE account SET credit=credit

該語句不會對值作任何更改！這表明，允許注釋以“--”開始會產生嚴重后果。

采用MySQL服務器3.23.3和更高版本中的這類注釋方法，“credit--1”實際上很安全。

另一個安全特性是，mysql命令行客戶端將刪除所有以“--”開頭的行。

僅當使用高于3.23.3的MySQL時，下述信息才有意義：

如果有1個文本文件形式的SQL程序，該文件包含“--”注釋，應按下述方式使用replace實用工具，將其轉換為使用“#”字符的注釋：

shell> replace " --" " #" < text-file-with-funny-comments.sql \

???????? | mysql db_name

而不是通常的：

shell> mysql db_name < text-file-with-funny-comments.sql

你也可以編輯注釋文件，將“--”注釋更改為“#”注釋：

shell> replace " --" " #" -- text-file-with-funny-comments.sql

使用下述命令將其改回去：

shell> replace " #" " --" -- text-file-with-funny-comments.sql

通常情況下，當你試圖INSERT或UPDATE會導致主鍵、唯一鍵或外鍵沖突的行時，將出現錯誤。如果你正在使用事務性存儲引擎時，如InnoDB，MySQL會自動回滾語句。如果你正在使用非事務性存儲引擎，MySQL將在出錯的行上停止執行語句，剩余的行也不再處理。

如果你希望忽略這類鍵沖突，可使用MySQL支持的、用于INSERT和UPDATE的IGNORE關鍵字。在這種情況下，MySQL將忽略任何鍵沖突，并繼續處理下一行。請參見13.2.4節，“INSERT語法”。請參見3.2.10節，“UPDATE語法”。

使用mysql_info() C API函數，能夠獲取關于實際插入或更新行數的信息。請參見25.2.3.34節，“mysql_info()”。在MySQL 4.1和更高版本中，也能使用SHOW WARNINGS語句。請參見13.5.4.22節，“SHOW WARNINGS語法”。

目前，只有InnoDB表支持外鍵。請參見15.2.6.4節，“FOREIGN KEY約束”。計劃在MySQL 5.1中實施對MyISAM表的外鍵支持。

在MySQL 5.0.2之前，MySQL對非法或不當值并不嚴厲，而且為了數據輸入還會強制將它們變為合法值。在MySQL 5.0.2和更高版本中，保留了以前的默認行為，但你可以為不良值選擇更傳統的處理方法，從而使得服務器能夠拒絕并放棄出現不良值的語句。本節介紹了MySQL的默認行為（寬大行為），新的嚴格的SQL模式，以及它們的區別。

如果你未使用嚴格模式，下述情況是真實的。如果將“不正確”的值插入到列，如將NULL值插入非NULL列，或將過大的數值插入數值列，MySQL會將這些列設置為“最可能的值”，而不是生成錯誤信息。

·???????? 如果試圖將超范圍的值保存到數值列，MySQL服務器將保存0（最小的可能值）取而代之，或最大的可能值。

·???????? 對于字符串，MySQL或保存空字符串，或將字符串盡可能多的部分保存到列中。

·???????? 如果打算將不是以數值開頭的字符串保存到數值列，MySQL將保存0。

·???????? MySQL允許將特定的不正確日期值保存到DATE和DATETIME列（如“2000-02-31”或“2000-02-00”）。其觀點在于，驗證日期不是SQL服務器的任務。如果MySQL能保存日期值并準確檢索相同的值，MySQL就能按給定的值保存它。如果日期完全不正確（超出服務器能保存的范圍）將在列中保存特殊的日期值“0000-00-00”取而代之。

·???????? 如果試圖將NULL值保存到不接受NULL值的列，對于單行INSERT語句，將出現錯誤。對于多行INSERT語句或INSERT INTO ... SELECT語句，MySQL服務器會保存針對列數據類型的隱含默認值。一般情況下，對于數值類型，它是0，對于字符串類型，它是空字符串('')，對于日期和時間類型是“zero”。在13.1.5節，“CREATE TABLE語法”一節中，討論了隱含的默認值。

·???????? 如果INSERT語句未為列指定值，如果列定義包含明確的DEFAULT子句，MySQL將插入默認值。如果在定義中沒有這類DEFAULT子句，MySQL會插入列數據類型的隱含默認值。

采用前述規則的原因在于，在語句開始執行前，無法檢查這些狀況。如果在更新了數行后遇到這類問題，我們不能僅靠回滾解決，這是因為存儲引擎可能不支持回滾。中止語句并不是良好的選擇，在該情況下，更新完成了“一半”，這或許是最差的情況。對于本例，較好的方法是“僅可能做到最好”，然后就像什么都未發生那樣繼續。

在MySQL 5.0.2和更高版本中，可以使用STRICT_TRANS_TABLES或STRICT_ALL_TABLES SQL模式，選擇更嚴格的處理方式。請參見5.3.2節，“SQL服務器模式”。

STRICT_TRANS_TABLES的工作方式：

·???????? 對于事務性存儲引擎，在語句中任何地方出現的不良數據值均會導致放棄語句并執行回滾。

·???????? 對于非事務性存儲引擎，如果錯誤出現在要插入或更新的第1行，將放棄語句。（在這種情況下，可以認為語句未改變表，就像事務表一樣）。首行后出現的錯誤不會導致放棄語句。取而代之的是，將調整不良數據值，并給出告警，而不是錯誤。換句話講，使用STRICT_TRANS_TABLES后，錯誤值會導致MySQL執行回滾操作，如果可以，所有更新到此為止。

要想執行更嚴格的檢查，請啟用STRICT_ALL_TABLES。除了非事務性存儲引擎，它與STRICT_TRANS_TABLES等同，即使當不良數據出現在首行后的其他行，所產生的錯誤也會導致放棄語句。這意味著，如果錯誤出現在非事務性表多行插入或更新過程的中途，僅更新部分結果。前面的行將完成插入或更新，但錯誤出現點后面的行則不然。對于非事務性表，為了避免這種情況的發生，可使用單行語句，或者在能接受轉換警告而不是錯誤的情況下使用STRICT_TRANS_TABLES。要想在第1場合防止問題的出現，不要使用MySQL來檢查列的內容。最安全的方式（通常也較快）是，讓應用程序負責，僅將有效值傳遞給數據庫。

有了嚴格的模式選項后，可使用INSERT IGNORE或UPDATE IGNORE而不是不帶IGNORE的INSERT或UPDATE，將錯誤當作告警對待。

ENUM和SET列提供了定義僅能包含給定值集合的列的有效方式。但是，從MySQL 5.0.2起，ENUM和SET不是實際約束。其原因與不重視NOT NULL的原因一樣。請參見1.8.6.2節，“對無效數據的約束”。

ENUM列總有1個默認值。如果未指定默認值，對于包含NULL的列，默認值為NULL；否則，第1個枚舉值將被當作默認值。

如果在ENUM列中插入了不正確的值，或者，如果使用IGNORE將值強制插入了ENUM列，會將其設置為保留的枚舉值0，對于字符串情形，將顯示為空字符串。請參見11.4.4節，“ENUM類型”。

如果在SET列中插入了不正確值，該值將被忽略。例如，如果列能包含值“a”、“b”和“c”，并賦值“a,x,b,y”，結果為“a,b”。請參見11.4.5節，“SET類型”。

從5.0.2開始，可以對服務器進行配置，以使用嚴格的SQL模式。請參見5.3.2節，“SQL服務器模式”。啟用嚴格模式后，ENUM或SET列的定義可作為對輸入至列的值的約束。如果值不滿足下述條件，將出現錯誤：

·???????? ENUM值必須是在列定義中給出的值之一，或內部的數字等同物。該值不能是錯誤值（即，0或空字符串）。對于定義為ENUM('a','b','c')的列，諸如''、'd'和'ax'等，均是非法的，并將被拒。

·???????? SET值必須是空字符串，或由1個或多個在列定義中給出的且用逗號隔開的值組成。 對于定義為SET('a','b','c')的列，諸如'd'和'a,b,c,d'等，均是非法的，并將被拒。

如果使用了INSERT IGNORE或UPDATE IGNORE，在嚴格模式下，可抑制無效值導致的錯誤。在這種情況下，將生成警告而不是錯誤。對于ENUM，值將作為錯誤成員(0)插入。對于SET，會將給定值插入，但無效的子字符串將被刪除。例如，'a,x,b,y'的結果是'a,b'，就像前面介紹的那樣。