MySQL中文參考手冊

oraclelang

ISAM表處理器--穩定
它管理所有在MySQL 3.22和早期版本中的數據的存儲和檢索。在所有MySQL版本中，代碼中已經沒有一個單獨（報告的）錯誤。得到一個損壞的數據庫表的唯一已知方法是在一個更新中途殺死服務器，即使這樣也不大可能破壞任何數據而不能挽救，因為所有數據在每個查詢之間被倒入(flush)到磁盤，而且從來沒有一個有關由于MySQL中的錯誤而丟失數據的錯誤報告。
MyISAM 表處理器-- Beta  
這是 MySQL 3.23的新功能，它大部分是基于ISAM表代碼但有很多新的有用的功能。
語法處理器和詞法分析器 --穩定
很長時間沒有一個在這個系統中的錯誤報告。

oraclelang

C 客戶代碼--穩定
沒有已知的問題。在早期的 3. 20版本中，在發送/接收緩衝器的大小上有一些限制。 3.21.x後，現在緩衝器的大小是動態的，可到一個24M的缺省值。
標准客戶程序--穩定
這些包括mysql、mysqladmin和mysqlshow、mysqldump及mysqlimport。
基本結構式查詢語言--穩定
基本SQL函數系統、字符串類和動態內存處理，本系統中未見單獨報告的錯誤。
查詢優化程序--穩定

oraclelang

範圍優化程序-- Gamma  
　
Join優化器--穩定
　
鎖定-- Gamma  
這是非常依賴于系統的，在某些系統上，用標准操作系統鎖定(fcntl())有很大問題，在這些情況下，你應該用選項--skip-locking咝蠱ySQL守護程序。當使用NFS挂載的文件系統，已知在一些 Linux 系統上和SunOS上出現問題。
Linux 線程-- Gamma  
唯一發現的問題式fcntl()調用，它通過使用mysqld的--skip-locking選項解決。一些人已經報告了0.5版中的鎖定問題。
Solaris 2.5 + pthreads --穩定
我們在我們的開發工作中使用。

oraclelang

我們在我們的開發工作中使用。
MIT-pthreads (其他系統)-- Gamma  
自從 3.20.15版以來，沒有報告的錯誤，而且從3.20.16開始沒有已知的錯誤。在一些系統上，在一些操作是相當慢時(在每查詢之間有 1/20秒的睡眠 )有一個“功能失效”。當然，MIT-pthreads 可能使任何事情慢一點，但是基于索引的SELECT語句通常在一個時幀內完成，因此不應該有一個mutex 鎖定/線程的把戲。
其他線程實現 -- Alpha - Beta  
移植到其他系統仍然是很新的並且可能有錯誤，可能是在MySQL中，但是最通常的是線程實現本身。
LOAD DATA ... ,INSERT ... SELECT --穩定
一些人已經認為他們在這里發現了錯誤，但是這些經常多是誤解。請在報告問題前檢查手冊！
ALTER TABLE --穩定

oraclelang

其他線程實現 -- Alpha - Beta  
移植到其他系統仍然是很新的並且可能有錯誤，可能是在MySQL中，但是最通常的是線程實現本身。
LOAD DATA ... ,INSERT ... SELECT --穩定
一些人已經認為他們在這里發現了錯誤，但是這些經常多是誤解。請在報告問題前檢查手冊！
ALTER TABLE --穩定
在 3.22.12中有小的改變。
DBD --穩定
現在由 Jochen  Wiedmann 維護了。
mysqlaccess --穩定

oraclelang

由 Yves  Carlier 編寫並維護。
GRANT -- Gamma  
MySQL 3.22.12.做了很大改變。
MyODBC （使用 ODBC  SDK 2.5 )-- Gamma  
它與一些程序似乎工作得很好。
TcX 為付費客戶提供電子郵件的支持，但是MySQL郵件列表通常提供常見問題的答案，錯誤通常馬上用一個補丁修補，對嚴重的錯誤，幾乎總是有新的版本發行。

oraclelang

1.6 順應2000年（Year 2000 compliance）
MySQL本身己沒有2000年有問題( Y2K ):

MySQL使用Unix時間函數並且在2069年前沒有日期問題, 所有2位年份被認為在1970年到2069年的範圍，這意味著如果在一個year類型的列中存儲的01，MySQL把它當作2001。
所有MySQL日期函數存儲在一個文件'sql/time.cc'中，並且很仔細地編碼保証是2000年安全的 。
MySQL 3.22 和以後的版本，新的YEAR類型的列能在一個字節中存儲0年和1901年到2155年，並用使用2或4位顯示它們。

oraclelang

所有MySQL日期函數存儲在一個文件'sql/time.cc'中，並且很仔細地編碼保証是2000年安全的 。
MySQL 3.22 和以後的版本，新的YEAR類型的列能在一個字節中存儲0年和1901年到2155年，並用使用2或4位顯示它們。
你可以用一種不是Y2K-safe的方式使用 MySQL應用程序來深入該問題。例如，許多老的應用程序使用2位數字(它有二義性)而非4位數字存儲或操作年份，這個問題可能與使用諸如00或99作為“丟失的”值的提示的應用程序混淆起來。

很不幸，這些問題可能很難修複，因為不同的應用程序可能由不同程序員編寫，其中每一個可能使用了不同的約定和日期處理函數。

這里是簡單的示範，顯示MySQL在 2030 年之前沒有任何日期問題。

oraclelang

mysql> DROP TABLE IF EXISTS y2k;
mysql> CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp);
mysql> INSERT INTO y2k VALUES ("1998-12-31","1998-12-31 23:59:59",19981231235959);
mysql> INSERT INTO y2k VALUES ("1999-01-01","1999-01-01 00:00:00",19990101000000);
mysql> INSERT INTO y2k VALUES ("1999-09-09","1999-09-09 23:59:59",19990909235959);
mysql> INSERT INTO y2k VALUES ("2000-01-01","2000-01-01 00:00:00",20000101000000);
mysql> INSERT INTO y2k VALUES ("2000-02-28","2000-02-28 00:00:00",20000228000000);
mysql> INSERT INTO y2k VALUES ("2000-02-29","2000-02-29 00:00:00",20000229000000);
mysql> INSERT INTO y2k VALUES ("2000-03-01","2000-03-01 00:00:00",20000301000000);
mysql> INSERT INTO y2k VALUES ("2000-12-31","2000-12-31 23:59:59",20001231235959);
mysql> INSERT INTO y2k VALUES ("2001-01-01","2001-01-01 00:00:00",20010101000000);

oraclelang

mysql> INSERT INTO y2k VALUES ("2000-02-28","2000-02-28 00:00:00",20000228000000);
mysql> INSERT INTO y2k VALUES ("2000-02-29","2000-02-29 00:00:00",20000229000000);
mysql> INSERT INTO y2k VALUES ("2000-03-01","2000-03-01 00:00:00",20000301000000);
mysql> INSERT INTO y2k VALUES ("2000-12-31","2000-12-31 23:59:59",20001231235959);
mysql> INSERT INTO y2k VALUES ("2001-01-01","2001-01-01 00:00:00",20010101000000);
mysql> INSERT INTO y2k VALUES ("2004-12-31","2004-12-31 23:59:59",20041231235959);
mysql> INSERT INTO y2k VALUES ("2005-01-01","2005-01-01 00:00:00",20050101000000);
mysql> INSERT INTO y2k VALUES ("2030-01-01","2030-01-01 00:00:00",20300101000000);
mysql> INSERT INTO y2k VALUES ("2050-01-01","2050-01-01 00:00:00",20500101000000);
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+