每个人都知道，在使用 InnoDB 作为引擎的表中，诸如此类SELECT COUNT(*) FROM mytable的查询非常不准确且非常慢，尤其是当表变大并且在该查询执行时不断插入/删除行时。
据我了解，InnoDB 不会将行数存储在内部变量中，这就是导致此问题的原因。
我的问题是：为什么会这样？存储这样的信息有那么难吗？在许多情况下，这是一个重要的信息。我看到是否要实现这样的内部计数的唯一困难是当涉及事务时：如果事务未提交，您是否计算它插入的行数？
PS：我不是数据库方面的专家，我只是一个将 MySQL 作为一个简单爱好的人。因此，如果我只是问一些愚蠢的问题，请不要过分挑剔：D。
我正在对本地 MySQL 数据库进行大型 INSERT
我有 2,000,000 行，现在我真的开始注意到速度变慢了。我一直听说 MySQL 的可扩展性不是很好
我希望这个数据库变得更大，而且我还有很多东西要插入
在这里使用亚马逊微型实例会有什么好处吗？
我不认为我的上传速度会成为瓶颈，所以我的逻辑是他们的分布式处理将使数据库更快。
事实证明，这更多是 CPU 利用率问题，但亚马逊的解决方案是否会更好，也许会针对更多可用处理器进行更优化？使用此逻辑，更昂贵的实例将具有更好的性能
但是这里涉及这么多变量，有没有人有这方面的经验要说？
我的网站将用户会话保留在 innodb 表中。这通常工作得很好，但一天几百次，INSERT 尤其是 UPDATE 语句运行得更慢。
我正在监控何时，结果证明通常是在机器人访问我的网站时（例如，googlebot 总是分配相同的会话，因此每次点击都需要在会话表上使用 UDPATE）。
我认为 google 对我的打击太大了，以至于 mysql 无法跟上更新相同的记录。通常更新需要几磨机，但我已经看到它达到了整整一秒。顺便说一句，我的表从来没有超过 7000 条记录。
知道我只有 1 个磁盘可供我使用，但仍有一些空闲内存可用，我想知道在这个特定表上增强 UPDATE 性能的最佳可能性是什么（我在其他表上没有遇到任何问题，因为它是少写密集）。