我们公司最近与特许经营签约,为他们的客户提供我们的POS (收银机)应用程序,导致我们每周有大约3-5个新的注册。目前,我们为每个新客户创建了应用程序数据库的副本,但我已经可以告诉您,这种方法可能最终会压垮我们。我们在想,对于每个表上通过某种形式的客户id标识的所有诊所,最好使用一个数据库。
现在我们进入了一个关于这个话题的辩论:一位同事说,有一个有50,000人的大表会让事情变得太慢,我们必须优化整个应用程序。另一位同事说,MySQL是为处理大型数据库而设计的,只要你在每个查询WHERE子句中指定客户端id,你就会收到数据的一个子集,速度几乎没有变化。
从大型表(100,000+)中选择数据子集与从小表中选择相同数量的行是否会有显着的速度差异?
此外,任何关于数据库设计的建议都将不胜感激。
发布于 2012-06-05 22:37:39
数据大小会影响性能,但如果索引正确,在50-100k记录中查找应该不会有任何问题。我使用的生产数据库(大约125万条记录)通过主键查找记录所需的时间可以忽略不计(不到0.005秒)。
不过,这取决于您的实际使用情况;您最终可能不得不优化一些查询并添加一些额外的索引。
发布于 2012-06-05 22:39:14
我会把它们分成几个较小的表,而不是一个又长又大的表。如果设计和索引正确,从长远来看,它应该会更快。
发布于 2012-06-05 22:40:12
为了提高select (read)查询的速度,您可以向查询所依据的列添加索引。
例如,如果按某种诊所标识符进行查询,则可以在该列上建立索引。这将帮助数据库遍历数据并找到符合您的条件的记录,而无需查看数据库中的每条记录(这是发生减速的地方)。如果将来按不同的条件查询(比方说日期),也可以在该列上建立索引。
请记住,添加索引将提高运行时性能,但会增加存储数据所需的物理磁盘大小。
https://stackoverflow.com/questions/10899264
复制相似问题