friend 们，有一个需要优化MySql数据库中聊天消息的保存。数据库类型并不重要。有聊天工作代码将消息存储在数据库表中，原则上单条消息一行。如果用户将会是 1000 -10 000 甚至更多，这是预期的，然后想象一下表中会有多少行。一种选择是将所有帖子放入缓存(文件，APC，甚至原则上可以存储在 Redis 中)，并且每 24 小时从 cron 中以 json 字符串的形式倒入主库一次。这样就得到了某一天这一条记录。
有必要优化方法。我认为这是真的吗？是否可以改进这个选项，或者有更好的？ 谢谢。
最佳答案
这个问题相当广泛 - 并且可以说是基于观点的。
但是...
您必须平衡此设计中的各种问题。一方面是性能和可扩展性，另一方面是构建和维护工作量，以及基础设施。在大多数情况下，工作量和成本方面都很重要。
因此，我的建议是从关系模型开始，没有缓存、分片等，但要有强大的数据库服务器、干净的关系模式以及对查询优化的大量关注。根据我的经验，这使得该应用程序对于数以万计的并发用户来说足够快，可以存储数千万或数亿行而不影响性能，并且对于构建和维护来说都是最具成本效益的。硬件通常比开发人员时间便宜得多。
我还建议建立一个性能和可扩展性测试系统，其中包含代表性数据和负载测试框架(类似于 Apache JMeter )。使用此系统来验证您的系统在负载和大量数据下的性能。设定性能和可扩展性目标，例如“1万并发用户，100万条旧消息，响应时间必须<1秒”。
在负载测试环境上运行定期测试，优化和调整架构、查询等，并继续这样做，直到您真的无处可去。
我的猜测是您需要大量流量才能到达该点。
一旦达到这一点，下一步可能就是缓存。这并非易事，尤其是在聊天应用程序中。您必须确保缓存能够收回成本(即缓存命中率足够高，足以产生影响；通常，这意味着至少 10%)，并且您不会花费太多时间来管理缓存缓存(例如，当您发布新消息时无效)，它弊大于利。
因此，证明您有真正的、可衡量的需求，然后进行优化。
关于mysql - 如何优化聊天消息在数据库中的存储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38552611/