top
Loading...
A.8.1.MySQL中的打開事宜
A.8.1. MySQL中的打開事宜

下面列出了已知問題,更正它們具有較高的優先級:

  • 如果將NULL值與使用ALL/ANY/SOME的子查詢進行比較,而且子查詢返回空的結果,比較操作會評估NULL的非標準結果而不是TRUEFALSE。在MySQL 5.1中將更正該問題。
  • 對于IN的線子查詢優化不像“=”那樣有效。
  • 即使使用了lower_case_table_names=2(允許MySQL記住數據庫名和表名使用的大小寫),對于函數DATABASE()或在各種日志內(在不區分大小寫的系統上),MySQL也不會記住數據庫名使用的大小寫情況。
  • 在復制操作中,撤銷FOREIGN KEY約束不工作,這是因為約束可能在從服務器上有另一個名稱。
  • REPLACE(以及具有REPLACE選項的LOAD DATA)不會觸發ON DELETE CASCADE
  • 如果未使用所有列而且僅使用DISTINCT列表中的列,在GROUP_CONCAT()中,DISTINCT不能與ORDER BY一起工作。
  • 如果1位用戶擁有長時間運行的事務,而且另1位用戶撤銷了在事務中更新的某1表,那么在表用于事務本身之前,存在較小的機會,會在二進制日志中包含DROP TABLE命令。我們計劃更正該問題,方法是讓DROP TABLE命令等待,直至表未在任何事務中使用為止。
  • 將大的整數值(介于2632641之間)插入數值或字符串列時,它將作為負值插入,這是因為該數值是在有符號整數環境下評估的。
  • 如果服務器運行在不具備二進制日志功能的條件下,FLUSH TABLES WITH READ LOCK不能屏蔽COMMIT,執行完整備份時這可能會導致問題(表間的一致性問題)。
  • 在某些情況下,作用在BDB表上的ANALYZE TABLE會導致表不可用,直至重啟mysqld為止。如果出現該情況,請在MySQL錯誤文件中查找下述形式的錯誤:
001207 22:07:56  bdb:  log_flush: LSN past current end-of-log
  • 在所有事務完成之前,不要在BDB表(正在其上運行多語句事務)上執行ALTER TABLE(可能會忽略事務)。
  • 對于正在使用INSERT DELAYED的表,在其上執行ANALYZE TABLEOPTIMIZE TABLEREPAIR TABLE時,可能會導致問題。
  • 在表上執行LOCK TABLE ...FLUSH TABLES ...時,不保證沒有完成一半的事務。
  • BDB打開的速度相對較慢。如果你在數據庫上有很多BDB表,如果未使用“-A”選項或正使用再混編功能,要想在數據庫上使用mysql客戶端,需要花費較長的時間。當你有大的表高速緩沖時,這點尤其明顯。
  • 復制功能采用了查詢級日志功能:主服務器將已執行的查詢寫入二進制日志。這是一種速度很快、簡潔和有效的記錄方法,在大多數情況下工作良好。

如果以特定的方式設計查詢,使得數據更改是非決定性(通常不推薦,即使在復制之外也同樣),主服務器和從服務器上的數據將變得不同。

例如:

  • 將0或NULL值插入AUTO_INCREMENT列中的CREATE ... SELECT或INSERT ... SELECT語句。
  • DELETE,如果從具有ON DELETE CASCADE屬性的外鍵的表中刪除行。
  • REPLACE ... SELECT、INSERT IGNORE ... SELECT,如果在插入的數據中具有重復鍵。

當且僅當前述查詢沒有保證決定行順序的ORDER BY子句時。

例如,對于不具有ORDER BYINSERT ... SELECTSELECT可能會以不同的順序返回行(它會導致具有不同等級的行,從而導致AUTO_INCREMENT列中的不同數值),具體情況取決于優化器在主服務器和從服務器上所作的選擇。

在主服務器和從服務器上,查詢將進行不同的優化,僅當:

  • 使用不同的存儲引擎在主服務器上而不是從服務器上保存表。(能夠在主服務器和從服務器上使用不同的存儲引擎。例如,如果從服務器具有較少的可用磁盤空間,可以在主服務器上使用InnoDB,但在 從服務器桑使用MyISAM)。
  • 在主服務器和從服務器上,MySQL緩沖區大小是不同的(key_buffer_size等)。
  • 在主服務器和從服務器上運行不同的MySQL版本,版本間的優化器代碼也不同。

該問題也會影響使用mysqlbinlog|mysql的數據庫恢復。

避免該問題的最簡單方法是,為前述的非決定性查詢增加ORDER BY子句,以確保總是以相同的順序保存或更改行。

在將來的MySQL版本中,需要時,我們將自動增加ORDER BY子句。

下面列出了已知的事宜,這些事宜將在恰當的時候更正:

  • 日志文件名基于服務器主機名(如果未使用啟動選項指定文件名的話)。如果更改了主機名,你將不得不使用諸如“--log-bin=old_host_name-bin”等選下美國。另一種選擇是重命名舊文件,以反映主機名變更情況(如果是二進制日志,需要編輯二進制日志索引文件,并更正binlog名稱)。請參見5.3.1節,“mysqld命令行選項”。
  • Mysqlbinlog不刪除執行LOAD DATA INFILE命令后遺留的臨時文件。請參見8.6節,“mysqlbinlog:用于處理二進制日志文件的實用工具”。
  • RENAME不能與TEMPORARY表一起工作,也不能與MERGE表中使用的表一起工作。
  • 由于表定義文件的保存方式,不能在表名、列名或枚舉中使用字符255CHAR(255))。按照安排,當我們實施了新的表定義格式文件時,將在5.1版中更正該問題。
  • 使用SET CHARACTER SET時,不能在數據庫、表和列名中使用轉換的字符。
  • 不能在LIKE ... ESCAPE中與ESCAPE一起使用_’或‘%’。
  • 如果你有1DECIMAL列,其中,相同的數值以不同的格式保存(例如,+01.001.0001.00),GROUP BY可能會將每個值當作不同的值。
  • 使用MIT-pthreads時,不能在另一個目錄下創建服務器。這是因為它需要更改MIT-pthreads,我們不太會更正該問題。請參見2.8.5 MIT-pthreads注意事項”
  • GROUP BYORDER BYDISTINCT中,不能可靠地使用BLOBTEXT值。在這類情況下,與BLOB值進行比較時,僅使用最前的max_sort_length字節。max_sort_length的默認值是1024,可在服務器啟動時或運行時更改它。
  • 數值計算是使用BIGINTDOUBLE(正常情況下均為64位長)進行的。你所能獲得的精度取決于函數。通用規則是位函數是按BIGINT精度執行的,IFELT()是按BIGINTDOUBLE精度執行的,其余的函數是按DOUBLE精度執行的。對于除位字段外的其他數,如果大于63位(9223372036854775807),應避免使用無符號長long值。
  • 1個表中,最多能有255ENUMSET列。
  • MIN()MAX()以及其他聚合函數中,MySQL目前會根據其字符串值比較ENUMSET列,而不是根據字符串在集合中的相對位置。
  • mysqld_safe會將來自mysqld的所有消息再定向到mysqld日志。與之相關的1個問題是,如果你執行mysqladmin refresh關閉并再次打開日志,stdoutstderr仍會被重定向到舊的日志。如果你以廣義方式使用“--log”應編輯mysqld_safe以記錄到host_name.err而不是host_name.log,以便通過刪除它并執行mysqladmin refresh,方便地收回為舊日志分配的空間。
  • UPDATE語句中,列從左向右更新。如果引用了已更新的列,你將得到更新值而不是原始值。例如,下述語句會將KEY增加2,而不是1
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
  • 你可以在相同查詢中引用多個臨時表,但不能引用任何給定的臨時表1次以上。例如,下述語句不能正常工作:
mysql> SELECT * FROM temp_table, temp_table AS t2;
錯誤1137:不能再次打開表:'temp_table'
  • 當你在聯合操作中使用“隱含”列時,與未使用隱含列相比,優化器將以不同的方式處理DISTINCT。在聯合操作中,隱含列將作為結果的組成部份計數(即使未顯示),但在正常查詢中,隱含列不參與DISTINCT比較。在以后,我們可能會更改該情況,在執行DISTINCT時不比較隱含列。

例如:

SELECT DISTINCT mp3id FROM band_downloads
       WHERE userid = 9 ORDER BY id DESC;

以及

SELECT DISTINCT band_downloads.mp3id
       FROM band_downloads,band_mp3
       WHERE band_downloads.userid = 9
       AND band_mp3.id = band_downloads.mp3id
       ORDER BY band_downloads.id DESC;

在第2種情況下,使用MySQL服務器3.23.x,可在結果集中獲得2個等同行(這是因為,隱藏ID列中的值可能不同)。

注意,在結果集中,僅對不含ORDER BY列的查詢才會出現該情況。

  • 如果在返回空集的查詢上執行PROCEDURE,在某些情況下,PROCEDURE不轉換列。
  • 創建具有MERGE類型的表時,不檢查基本表是否具有兼容的類型。
  • 如果使用ALTER TABLEMERGE表中使用的表增加了UNIQUE索引,然后在MERGE表上增加了正常索引,如果在表中存在舊的、非UNIQUE鍵,對于這些表,鍵順序是不同的。這是因為,ALTER TABLE會將UNIQUE索引放在正常索引之前,以便能盡早檢測到重復的鍵。
 
作者:mysql.com
來源:http://dev.mysql.com/doc/refman/5.1/zh/problems.html
北斗有巢氏 有巢氏北斗