我们有一组表，其中包含元级别数据，如组织，组织用户，组织部门等 . 所有这些表都将被阅读，只需很少的写操作 . 此外，表格大小非常小（最大记录数量约为30K - 40K）
另一组表存储OLTP数据，如账单交易，用户操作等，这些数据将同时读写 . 这些表格非常庞大（每张表约3000万条记录）
对于第一组表，我们计划使用MyISAM，第二组使用InnoDb引擎 . 我们的许多功能还需要来自这两组的 table 上的JOINS .
使用InnoDB表加入MyISAM表时是否存在任何性能问题？此外，还有任何其他可能的问题（数据库备份，调整等），我们可能会遇到这种设计？
任何反馈将不胜感激 .
2 回答
立即跳出来的是 MyISAM .
ASPECT＃1：JOIN本身
每当有涉及MyISAM和InnoDB的连接时，由于MyISAM参与查询而且MVCC无法应用于MyISAM数据，InnoDB表将最终具有表级锁定行为而不是行级锁定 . 在某些情况下，MVCC甚至无法应用于InnoDB .
ASPECT＃2：MyISAM的参与
从另一个角度来看，如果通过INSERT，UPDATE或DELETE更新任何MyISAM表，JOIN查询中涉及的MyISAM表将从其他数据库连接中锁定，并且JOIN查询必须等到可以读取MyISAM表 . 不幸的是，如果在JOIN查询中混合使用InnoDB和MyISAM，InnoDB表将不得不像JOIN查询中的MyISAM合作伙伴一样经历间歇性锁定，因为它被写入了 .
请记住MVCC will still permit READ-UNCOMMITTED and REPEATABLE-READ transactions to work just fine and let certain views of data be available for other transactions. I cannot say the same for READ-COMMITTED and SERIALIZABLE .
ASPECT＃3：查询优化器
MySQL依靠索引基数来确定优化的EXPLAIN计划 . 索引基数在MyISAM表中是稳定的，直到表中发生了很多INSERT，UPDATE和DELETE，您可以针对MyISAM表定期运行
OPTIMIZE TABLE. InnoDB索引基数绝对不稳定！如果运行SHOW INDEXES FROM *innodbtable*;，则每次运行该命令时都会看到索引基数发生变化 . 那是因为InnoDB会潜入索引来估计基数 . 即使您对InnoDB表运行OPTIMIZE TABLE，也只会对表进行碎片整理 .OPTIMIZE TABLE将在内部运行ANALYZE TABLE以生成针对表的索引统计信息 . 这适用于MyISAM . InnoDB忽略了它 .我的建议是全力以赴，将所有内容转换为InnoDB并相应地优化您的设置 .
更新2012-12-18 15:56美国东部时间
信不信由你，有still an open ticket on InnoDB/MyISAM joining during a SELECT FOR UPDATE . 如果您阅读它，它会将分辨率总结如下：DON'T DO IT !!! .
我认为事务管理不会正常工作或根本不工作，因为MyISAM表不能处理它 .