我们有一组表，其中包含组织、组织用户、组织部门等元数据。所有这些表都将被大量读取，而写入操作很少。此外，表的大小会非常小（最大记录数约为 30K - 40K）
另一组表存储 OLTP 数据，如账单交易、用户操作等，这些数据将是读写繁重的。这些表会非常大（每个表大约有 3000 万条记录）
对于第一组表，我们计划使用 MyISAM，而对于第二组表，我们计划使用 InnoDb 引擎。我们的许多功能还需要在这 2 个集合中的表上进行 JOINS。
将 MyISAM 表与 InnoDB 表连接时是否存在任何性能问题？此外，我们在这种设计中可能会遇到任何其他问题（数据库备份、调整等）吗？
任何反馈都将不胜感激。
【问题讨论】：
我认为事务管理不能正常工作或根本不能正常工作，因为 MyISAM 表不能处理它。
【讨论】：
我立即跳出来的是 MyISAM。
每当有涉及 MyISAM 和 InnoDB 的连接时，由于 MyISAM 参与查询，InnoDB 表最终将具有表级锁定行为而不是行级锁定，并且 MVCC 不能应用于 MyISAM 数据。 MVCC 在某些情况下甚至不能应用于 InnoDB。
从另一个角度来看，如果通过 INSERT、UPDATE 或 DELETE 更新任何 MyISAM 表，则 JOIN 查询中涉及的 MyISAM 表将与其他 DB 连接锁定，并且 JOIN 查询必须等到 MyISAM 表可以读。不幸的是，如果在 JOIN 查询中混合使用 InnoDB 和 MyISAM，则 InnoDB 表将不得不像在 JOIN 查询中的 MyISAM 伙伴一样遇到间歇性锁定，因为被阻止写入。
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 并相应地优化您的设置。
信不信由你，有still an open ticket on InnoDB/MyISAM joining during a SELECT FOR UPDATE。如果您阅读它，它将解决方案总结如下：DON'T DO IT !!!。
【讨论】：