我们有一款产品为不同的客户使用不同的 MySQL shemas，并且有一个 Java 应用程序为每个客户使用不同的持久性单元。这使得在不重新部署应用程序的情况下添加客户变得困难。
我们计划使用单个 MySQL 数据库模式来保存所有客户，每个表都有一个字段，该字段是一个客户的 KEY，这样添加一个新客户只需几次 SQL 更新/插入即可。
在 MySQL 中处理此类数据的最佳方法是什么...MySQL 是否提供按键或类似方式分区表。这种方法可能存在哪些性能问题？
最佳答案
这里有几个问题:
架构设计问题
分区问题
mySQL 可以处理 HASH MAP 查询 O(1)
架构设计问题: 是的，这比为每个客户启动一个新应用程序要好得多。
mySQL 能否处理 O(1) 的 HASH MAP 查询 是的，如果数据保留在内存中并且有足够的 CPU 周期，mySQL 可以轻松地每秒执行 300K 选择。否则，如果数据受 I/O 限制并且磁盘子系统未饱和，则 mySQL 可以轻松地每秒执行 20-30K 选择，具体取决于流量模式、并发性以及数据库磁盘子系统可以执行的 IOPS 数量。
分区 在讨论 mySQL 时，分区有不同的含义。分区是一种存储引擎，位于 mySQL 中另一个存储引擎之上，用于将数据分配到某个表，但将一组分区表作为单个表公开给调用应用程序。分区还可能意味着让某些数据库执行所有表的子集。在您的上下文中，我认为您是在问如果您按客户联合会对性能产生什么影响。 IE。如果需要，您可以使用相同的架构为每个客户分配一个数据库吗？这个概念更符合分片的理念，将数据视为一个整体，并为每个数据单元分配资源。一位客户。
我给你的建议 使每个客户的架构都相同。对客户将执行的所有查询进行基准测试。即查询模式。验证使用 EXPLAIN 的每个查询不会生成文件排序或临时表，也不会一次扫描 100K 行，并且您应该能够毫无问题地进行扩展。一旦遇到单个或一组盒子接近 IOP 上限的问题，请考虑拆分数据。
关于MySQL按客户分区，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14851618/