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被儲存在檔案系統上，這一點與它使用的儲存引擎無關。