我心中的MySQL性能问题[关闭]答案

【问题标题】：MySQL performance issues in my mind [closed]我心中的MySQL性能问题[关闭]
【发布时间】：2018-06-26 07:08:57
【问题描述】：

首先，我不是一个经验丰富的开发人员，我正在使用 PHP、MySQL 和 Javascript 制作中型应用程序。

虽然有些东西让我很难在每个项目之前设计一个 MySQL InnoDB 数据库。这就是性能。我总是很担心如果我要创建一个规范化的数据库方案，当我必须将几个表（如 5-6）连接在一起时（那里通常是它们之间的一些多对多、多对一关系）当这 5-6 个表中的每一个都有大约 100k 行时，它会影响很多（负面）性能。

我通常拥有的这些项目是创建分析平台。因此，我预计总共会有大约 1 亿次点击，我通常必须将此表加入到许多其他表（每个表大约 100k 行）才能显示一些数据。我通常会制作点击的汇总表，但不能为其他表做同样的事情。

我不太确定我是否必须担心这个阶段的未来表现。目前，我正在积极管理其中一些具有 3000 万次以上点击的应用程序和我加入到这个具有 40k+ 行的 Clicks 表的表格。性能非常糟糕 - 选择操作通常需要超过 10-20 秒才能完成，而我相信我有适当的索引，innodb_buffer_pool_size 也是。

我读过很多关于优化数据库的关键是设计。这就是为什么我通常会在创建数据库方案之前对其进行大量思考。

我是否真的需要担心创建数据库方案，我必须加入 5-6 个多对多/多对一/一对多表，或者这很常见，MySQL 应该能够轻松处理这个负载？

在创建数据库方案之前我还有什么需要考虑的吗？

我通常的服务器设置是有一个具有 4GB RAM + 2 个 vCPU 的 MySQL 服务器来为数据库和一个具有 4GB RAM + 2 个 vCPU 的 WebServer 提供服务。他们都使用 Ubuntu 的 16.04 版本并使用最新的 MySQL (5.7.21) 和 PHP7-fpm。

【问题讨论】：

存在支持数亿行且性能合理的数据库。如今，4 GB 的 RAM 似乎很小。我可能会质疑您选择的技术。
您描述的是premature optimisation。可维护性、易于测试、标准实践等等，都比性能更重要直到您实际证明了性能问题。如果你过早地在性能上做出妥协，你可能会发现你优化了错误的区域，而你没有考虑到的是真正需要优化的地方，但是你现有的妥协已经变得更加困难了。如果您正在处理事务数据，则在规范化方面犯了很大的错误，如果您正在处理 Analytics，请考虑平面文件非规范化结构。
感谢大家的详细回复！
打开另一个问题来讨论“您无法总结的表格”。可能有一些技巧。
有“过度规范化”之类的东西。特别是，不要规范化“连续”值，例如FLOAT、DATETIME。

标签： mysql database performance server

【解决方案1】：

戈登是对的。 RDBMS 用于处理您的工作负载。

如果您使用虚拟机（云等）来托管您的东西，通常只需花更多的钱就可以增加您的 RAM、vCPU 数量和 IO 容量。但是，通常情况下，在 DBMS 性能问题上投入资金比投入更好的索引更有帮助。

在 100M 行的规模上，查询性能是一个合理的问题。随着项目的发展，您将需要重新访问 DBMS 索引以优化您实际使用的查询。所以计划一下。问题是，在您获得大量数据之前，您不能也不会知道您的实际性能问题是什么。

阅读此内容以预览即将发生的事情：https://use-the-index-luke.com/。

一条建议：对表进行分区通常不能解决性能问题，除非在非常特殊的情况下。

查找这个首字母缩写词：YAGNI。

然后去做你的项目。花你现在的努力让它发挥作用。

【讨论】：

感谢详细的回复，明白了！当它们出现时，我必须考虑性能问题，并尝试尽快让应用程序上线，而不是过多地考虑我无法预测的以后的性能问题。
我同意，只有一个小例外。因为ALTER TABLE 很痛苦，所以“过早地”仔细考虑数据类型。如果TINYINT UNSIGNED 和VARCHAR(20) 在可预见的未来足够用，不要盲目使用BIGINT 和TEXT。