我终于确信将我的小表放到一个大表中,但对于MySQL表来说究竟有多大？
我有一张18个字段的桌子.有些是TEXT,有些是短的,有些是VARCHAR(16)更长的VARCHAR(100).
现在我们每天大约有200,000行,每月600万+.有多大太大了？你有多少个字段或者只是行？
Joh*_*tle 16
对于"有多大太大"的问题,没有一个很好的通用解决方案 - 这些问题通常取决于您对数据的处理以及您的性能考虑因素.
表格大小有一些基本限制.您不能超过1000列.您的记录不能超过每个8k.这些限制根据数据库引擎而变化.(这里的是InnoDB.)
听起来你已经将几个不同的数据集合并到一个表中.您可能有一些字段可以告诉您此记录所属的数据集,以及一些数据字段和一些时间戳信息.这不是一个非常广泛的记录(除非您记录,例如,每个请求的所有输入参数.)您的主要问题是选择性.以有意义的方式为此表编制索引将是一项挑战.如果您的公共字段具有足够的选择性,您可以使用它们来获取所需的记录而无需查阅表格,这将是一个巨大的优势.(参见表扫描)
对于每天的那么多记录(基本上,一整天都是两秒钟,而且我假设你的峰值负载时间要高得多),你还要确保你专门考虑改进插入的优化速度.作为一般规则,更多索引=插入速度较慢.如果可以,请考虑将过时的记录完全归档到另一个表.在之前的工作场所,我们使用了上个月,前三个月,前六个月的档案策略,每个策略都在不同的表格中.另一个想法是删除旧记录.许多环境根本不需要超过特定日期的信息.挂在三个月前的记录记录往往是非常昂贵的.
最后,不要忽视桌子的物理存储.记录越薄,读取(或就此而言,插入)记录所需的物理IO就越少.您可以将索引存储在单独的物理硬盘驱动器上.如果您的记录中存在大量冗余数据,则存储压缩的表实际上可能是速度增加.如果你有一点点现金要烧钱,可以考虑一个好的RAID阵列的价值来分散数据.
所以,回答你的基本问题:这是很多记录,但仔细观察调整,这不会是一个问题.
小智 6
我有一个大约有 98M 行的表，并且整天都在发生插入/删除。我们将记录保存 90 天...我预计本月该表的行数约为 1 亿行。就我个人而言，我会以不同的方式设计数据库模式，但它是购买的，我们需要保持它的完整性，这样我们就不会失去任何供应商支持。
我们使用 mysql 复制（MASTER-MASTER）并在一个上执行插入/删除，并在另一个上执行查询。这确实有助于提高性能，因为在我们更改为使用复制之前，删除会锁定表并阻止查询。
使用此实现，我们没有遇到任何性能问题。
我还每周执行一次表优化......