1、 對子查詢的優化表現不佳。
2、 對復雜查詢的處理較弱
3、 查詢優化器不夠成熟
4、 性能優化工具與度量信息不足
5、 審計功能相對較弱
6、 安全功能不成熟，甚至可以說很粗糙。沒有用戶組與角色的概念，沒有回收權限的功能(僅僅可以授予權限)。當一個用戶從不同的主機/網絡以同樣地用戶名/密碼登錄之后，可能被當作完全不同的用戶來處理。沒有類似于
Oracle的內置的加密功能。
7、身份驗證功能是完全內置的。不支持LDAP，Active Directory以及其它類似的外部身份驗證功能。
8、
Mysql Cluster可能與你的想象有較大差異。
9、存儲過程與觸發器的功能有限。
10、垂直擴展性較弱。
11、不支持MPP(大規模并行處理)。
12、支持SMP(對稱多處理器)，但是如果每個處理器超過4或8個核(core)時，Mysql的擴展性表現較差。
13、對于時間、日期、間隔等時間類型沒有秒以下級別的存儲類型。
14、可用來編寫存儲過程、觸發器、計劃事件以及存儲函數的語言功能較弱。
15、沒有基于回滾(roll-back)的恢復功能，只有前滾(roll-forward)的恢復功能。
16、不支持快照功能。
17、不支持
數據庫鏈(database link)。有一種叫做Federated的存儲引擎可以作為一個中轉將查詢語句傳遞到遠程服務器的一個表上，不過，它功能很粗糙并且漏洞很多。
18、數據完整性檢查非常薄弱，即使是基本的完整性約束，也往往不能執行。
19、優化查詢語句執行計劃的優化器提示非常少。
20、只有一種表連接類型：嵌套循環連接(nested-loop)，不支持排序-合并連接(sort-merge join)與散列連接(hash join)。
21、大部分查詢只能使用表上的單一索引;在某些情況下，會存在使用多個索引的查詢，但是查詢優化器通常會低估其成本，它們常常比表掃描還要慢。
22、不支持位圖索引(bitmap index)。每種存儲引擎都支持不同類型的索引。大部分存儲引擎都支持B-Tree索引。
23、管理工具較少，功能也不夠成熟。
24、沒有成熟能夠令人滿意的IDE工具與調試程序。可能不得不在文本編輯器中編寫存儲過程，并且通過往表(調試日志表)中插入記錄的方式來做調試。
25、每個表都可以使用一種不同的存儲引擎。
26、每個存儲引擎在行為表現、特性以及功能上都可能有很大差異。
27、大部分存儲引擎都不支持外鍵。
28、默認的存儲引擎(MyISAM)不支持事務，并且很容易損壞。
29、最先進最流行的存儲引擎InnoDB由Oracle擁有。
30、有些執行計劃只支持特定的存儲引擎。特定類型的Count查詢，在這種存儲引擎中執行很快，在另外一種存儲引擎中可能會很慢。
31、執行計劃并不是全局共享的，，僅僅在連接內部是共享的。
32、全文搜索功能有限， 只適用于非事務性存儲引擎。 Ditto用于地理信息系統/空間類型和查詢。
33、沒有資源控制。一個完全未經授權的用戶可以毫不費力地耗盡服務器的所有內存并使其崩潰，或者可以耗盡所有CPU資源。
34、沒有集成商業智能(business intelligence)， OLAP 多維數據集等軟件包。
35、沒有與Grid Control類似的工具(http://solutions.mysql.com/go.php?id=1296&t=s)
36、沒有類似于RAC的功能。如果你問”如何使用Mysql來構造RAC”，只能說你問錯了問題。
37、不支持用戶自定義類型或域(domain)。
38、 每個查詢支持的連接的數量最大為61。
39、MySQL支持的
SQL語法(ANSI SQL標準)的很小一部分。不支持遞歸查詢、通用表表達式（Oracle的with 語句）或者窗口函數（分析函數）。支持部分類似于Merge或者類似特性的SQL語法擴展，不過相對于Oracle來講功能非常簡單。
40、 不支持功能列(基于計算或者表達式的列，Oracle11g 開始支持計算列，以及早期版本就支持虛列(rownum，rowid))。
41、不支持函數索引，只能在創建基于具體列的索引。
42、不支持物化視圖。
43、不同的存儲引擎之間，統計信息差別很大，并且所有的存儲引擎支持的統計信息都只支持簡單的基數(cardinality)與一定范圍內的記錄數(rows-in-a-range)。 換句話說，數據分布統計信息是有限的。更新統計信息的機制也不多。
44、沒有內置的負載均衡與故障切換機制。
45、復制(Replication)功能是異步的，并且有很大的局限性。例如，它是單線程的(single-threaded)，因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master。
46、 Cluster并不如想象的那么完美。或許我已經提過這一點，但是這一點值得再說一遍。
47、數據字典(INFORMATION_SCHEMA)功能很有限，并且訪問速度很慢(在繁忙的系統上還很容易發生崩潰)。
48、不支持在線的Alter Table操作。
49、不支持Sequence。
50、類似于ALTER TABLE或CREATE TABLE一類的操作都是非事務性的。它們會提交未提交的事務，并且不能回滾也不能做災難恢復。Schame被保存在文件系統上，這一點與它使用的存儲引擎無關。
我本人比較關心的幾點:
1、對子查詢的優化表現不佳
2、對復雜查詢的處理較弱
4、性能優化工具與度量信息不足
12、支持SMP(對稱多處理器)，但是如果每個處理器超過4或8個核(core)時，Mysql的擴展性表現較差。
15、沒有基于回滾(roll-back)的恢復功能，只有前滾(roll-forward)的恢復功能。
18、數據完整性檢查非常薄弱，即使是基本的完整性約束，也往往不能執行。
20、只有一種表連接類型:嵌套循環連接(nested-loop)，不支持排序-合并連接(sort-merge join)與散列連接(hash join)。
21、大部分查詢只能使用表上的單一索引；在某些情況下，會存在使用多個索引的查詢，但是查詢優化器通常會低估其成本，它們常常比表掃描還要慢。
26、每個存儲引擎在行為表現、特性以及功能上都可能有很大差異。
28、默認的存儲引擎(MyISAM)不支持事務，并且很容易損壞。
30、有些執行計劃只支持特定的存儲引擎。特定類型的Count查詢，在這種存儲引擎中執行很快，在另外一種存儲引擎中可能會很慢。
31、執行計劃并不是全局共享的，僅僅在連接內部是共享的。
33、沒有資源控制。一個完全未經授權的用戶可以毫不費力地耗盡服務器的所有內存并使其崩潰，或者可以耗盡所有CPU資源。
45、復制(Replication)功能是異步的，并且有很大的局限性。例如，它是單線程的(single-threaded)，因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master。
46、Cluster并不如想象的那么完美。或許我已經提過這一點，但是這一點值得再說一遍。
47、數據字典(INFORMATION_SCHEMA)功能很有限，并且訪問速度很慢(在繁忙的系統上還很容易發生崩潰)。
48、不支持在線的Alter Table操作。
50、類似于ALTER TABLE或CREATE TABLE一類的操作都是非事務性的。它們會提交未提交的事務，并且不能回滾也不能做災難恢復。Schame被保存在文件系統上，這一點與它使用的存儲引擎無關。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters