我们有一个案例，我们必须在一个记录多达 146000000 条记录的表上记录一天数百万的状态更新。我不确定 MySQL 是否能做到这一点。这是完整的场景：
我们使用的是 MySQL 5.5。
我的担忧和问题是 - MySQL 是否能够满足我们的要求（我感觉当更新以上述速度发生时我们可能会看到死锁）？如果不能，我们应该怎么做才能构建上面所说的一切？
提前致谢，
【问题讨论】：
我建议你必须使用任何 nosql 数据库。像 cassandra 一样，与 mysql/ 相比，它的性能将提高 30% 到 40%
【讨论】：
是否可以将表格拆分为多个表格？例如。每小时/每天/每周/每月一张表
如果是，您可以为所需的时间间隔创建一个单独的表并单独存储更新。
或者您可以尝试通过另一个符号将数据分成多个表，例如按客户。
如果没有更多信息，很难给出建议。
你打算从表中收集一些统计数据吗？
【讨论】：
市场上有很多 nosql 数据库可用于您所拥有的相同用例。
您可以通过它解决所有问题。
【讨论】：
天哪……
我还记得 2002 年我们更换了 Oracle 数据库，因为要求是每天插入/更新 50M 条记录，并将记录保存至少 7 年，同时需要同时报告/监控；-)（一个 NMS 应用程序对于移动网络）
在说选择 NoSQL 或 NewSQL 或其他任何东西之前，了解大局会很有帮助。你f.ex。需要实时报告？复制？关键任务应用程序所需的在线备份和其他功能？
您的团队在 DBMS 技术方面的经验如何？除了 MySQL，您还使用过其他任何东西吗？
你提到死锁？你现在看到他们了吗？我想说，虽然不想伤害任何人的感情，死锁主要是由于糟糕的设计！从排队、事务封装、事务监视器、乐观并发等开始，有 100 多种方法可以避免或快速解决死锁。
对我来说，您提供的这些数字并没有那么高，但是无论您使用什么 DBMS，设计都会破坏性能。在不了解 ACID 的全套需求、SQL 兼容性和其他需求的情况下，我不建议在不完全了解真正需求和相关问题的情况下跳入 XyzzySQL 潮流。
所以，简而言之：您的数字并不那么令人担忧。我已经看到正在实施更大的系统（使用 InnoDB = money）。我已经看到 MySQL 很容易通过稳定的 24 小时负载来消化，比如每天 15M 的插入/更新混合负载，没有任何技巧和技巧。
如果您的需求放宽了，您可以采用“黑洞”或内存方法并写入非永久表，这些表将（随着时间的推移）复制到 MySQL 文件中的可靠存储。当您丢失“几秒钟或几分钟”的插入/更新并不重要时，这是一种很好的方法。
如果您有一个稳定的负载，但峰值有限，或者像许多实际应用一样，在一天中的特定时间段内有巨大的峰值负载，情况就大不相同了。
干杯，//贾里
【讨论】：