每天将有20到两千万行，这些行将在午夜时分删除以备下一天的数据。 mySQL可以处理2500万个索引行吗？什么是另一个好的解决方案？
答案 0 :(得分：9)
您提供的上下文信息非常少，但有时不使用数据库而是二进制/纯文本文件很好，可以 - 根据您的要求 - 更有效率维护。例如，如果它的传感器数据存储在二进制文件中，每个记录在一个已知的偏移处可能是一个很好的解决方案。您说每24小时删除一次数据似乎表明您可能不需要某些关系数据库解决方案的属性，如ACID，复制，集成备份等等，所以也许平面文件方法可以正常使用？
答案 1 :(得分：7)
我们的MySQL数据库有超过3亿行索引，我们只遇到运行速度有点慢的复杂连接问题 - 大多数都可以进行优化。
处理行没问题 - 我们表现的关键是好的索引。
考虑到您正在午夜丢弃信息，我还会查看MySQL分区，这将允许您删除表中的那一部分，同时允许第二天继续插入（如果需要）。
答案 2 :(得分：3)
问题不在于行数本身 - 而是您对数据库所做的事情。您是否只在白天进行插入，然后进行一些批量报告？或者，您是否每秒对数据进行数千次查询？插入/更新/删除？如果您在任何数据库平台上都有足够的负载，那么您可以使用单个表和单行（将其置于最极端）来最大化。我在具有40M行用户表的站点上使用MySQL 4.1 w / MyISAM（几乎不是最现代的东西）。它确实＆lt;我想是5ms查询。我们在不到200ms的时间内渲染页面。但是，我们设置了大量的缓存，因此查询的数量不是太多。而且，我们正在做简单的语句，如SELECT * FROM USER WHERE USER_NAME ='SMITH'
您能否对您的用例发表更多评论？
答案 3 :(得分：1)
如果您使用的是Windows，那么您可能会比使用SqlExpress 2008更糟糕，SqlExpress 2008应该可以轻松处理该负载，具体取决于您在其上创建的索引数量。只要你保持＆lt; 4GB的总db大小，应该不是问题。
答案 4 :(得分：0)
根据我的经验，mySQL往往不能很好地扩展。如果你必须有一个免费的解决方案，我会高度推荐postgreSQL。
另外（这可能是也可能不是你的问题），但请记住，如果你处理那么多数据，如果我没记错的话，mySQL数据库的最大大小是4太字节。
我认为mySQL中的最大行数没有实际限制，所以如果你必须使用mySQL，我认为它可以用于你想做的事情，但是对于生产系统我个人不会推荐它。
答案 5 :(得分：0)
作为一般解决方案，我也推荐使用PostgreSQL，但根据您的具体需求，其他解决方案可能更好/更快。例如，如果您在编写数据时不需要查询数据，TokyoCabinet（基于表格的API / TDB）可能更快，更轻量/更强大。
答案 6 :(得分：0)
我没有在mysql中查看它们，但这听起来像是table partitions的完美应用
答案 7 :(得分：0)
仅用作索引数据库并以文件形式存储它会更有效，因为您将在24小时内删除并且该过程将更快也不会给您的服务器带来负担