我本人比较关心的几点:
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被保存在文件系统上，这一点与它使用的存储引擎无关。
