我们公司最近与特许经营权签约，为他们的客户提供我们的 POS（收银机）应用程序，这导致我们每周有大约 3-5 个新注册。目前，我们为每个新客户创建应用程序数据库的副本，但我已经可以看出这种方法最终可能会让我们崩溃。我们在想也许最好为所有诊所使用一个数据库，这些诊所由每张表上的某种形式的客户 ID 标识。
现在我们就这个话题进行了一些辩论：一位同事说拥有一个包含 50,000 人的大表会使事情变得太慢，我们必须优化整个应用程序。另一位同事说 MySQL 是为处理大型数据库而设计的，只要您在每个查询 WHERE 子句中指定客户端 ID，您就会收到数据的一个子集，速度几乎没有变化。
从大表（100,000+）中选择数据子集与从较小表中选择相同数量的行是否有显着的速度差异？
此外，任何关于数据库设计方式的建议将不胜感激。
数据大小会影响性能，但是通过正确的索引，在 50-100k 记录中查找应该没有任何问题。我使用的生产数据库（约 125 万条记录）通过主键查找记录所需的时间可以忽略不计（少于 0.005 秒）。
仍然取决于您的实际使用情况；您最终可能不得不优化一些查询并添加一些额外的索引。
我会把它们分成几张小桌子，而不是一张又长又大的桌子。如果设计和索引正确，从长远来看应该会更快。
为了提高选择（读取）查询的速度，您可以为查询所依据的列添加索引。
例如，如果您通过某种诊所标识符进行查询，您可以在该列上放置一个索引。这将帮助数据库遍历数据并找到与您的条件匹配的记录，而无需查看数据库中的每条记录（这是发生减速的地方）。如果将来您按不同的条件（比如说日期）进行查询，您也可以在该列上放置一个索引。
请记住，添加索引会提高运行时性能，但会增加存储数据所需的物理磁盘大小。