mySQL 的速度和调优（10 亿行）答案

【问题标题】：Speed and tuning for mySQL (1billion rows)mySQL 的速度和调优（10 亿行）
【发布时间】：2017-12-23 15:15:28
【问题描述】：

我的公司有一个分析团队使用的 mySQL 服务器（通常一次 3-4 个）。最近，对于包含多达 10 亿行（10^9 条记录）的表的数据库，查询速度变慢了，其中一些甚至需要几天时间。

服务器主要特点： Linux OS-64 GB 内存- 3 TB 硬盘。

我们对微调一无所知，因此欢迎使用任何工具/经验法则来找出导致问题的原因或至少缩小问题范围。

Going to Workbench studio>Table inspector 我为我们最常使用的数据库找到了这些关键值：

数据库大小： ~500 GB
最大表大小：~80 GB
索引长度（对于最大的表）：~230 GB。该索引依赖于 6 个字段。
几乎没有 MyISAM 表，都是 InnoDB

理想情况下，我想以最简单的方式对服务器（更好）、数据库（更差）或两者（将来）进行微调，以加快速度。

我的问题：

这些值（500、80、230 GB）是否正常且可管理？中型服务器？
这种大小的索引 -230Gb- 比表本身大得多，这是否正常？
可以调整哪些参数/策略来解决此问题？我正在考虑内存日志或购买服务器 RAM，但很乐意调查任何合理的答案。

非常感谢。

【问题讨论】：

数据库调优是一项复杂的任务，不仅是服务器，查询也会影响性能。现在，除了 db 大小之外，您还没有告诉我们太多，所以我们在这里无能为力。告诉我们您的查询是什么，生成的计划是什么。性能问题应该包括EXPLAIN ANALYZE和一些关于表大小、索引、当前时间性能、期望时间等的信息。Slow是一个相对术语，我们需要一个真实的值来比较。 MySQL
公认的数据库调优很复杂，但我认为这些问题非常具体。我不包括 EXPLAIN_ANALYZE 因为我什至不知道那是什么。关于变慢：我说的是读取/加入表的查询（一个最多 10 亿条记录），正如所解释的那样需要 days （几天）运行（过去是几个小时，而DB 更小）。
致那些愿意关闭它的人：这可能不是服务器调优问题，主要是关于学习正确使用数据库。它应该保持打开状态。
我已经发布了EXPLAIN PLAN 的链接，如果您没有使用它，您的问题可能与索引有关，所以请先检查这些计划。还因为当数据库大小增加时，您的问题会变得最糟糕，这也指向您的查询进行全表扫描（再次坏索引）。您还可以使用分区来改善对大表的访问dev.mysql.com/doc/refman/5.7/en/partitioning-types.html

标签： mysql sql optimization database-administration database-tuning

【解决方案1】：

如果您正在管理这种规模的 MySQL 实例，那么值得您花时间阅读High Performance MySQL，这是关于 MySQL 调优的最佳书籍。我强烈建议您购买这本书并阅读它。

您的 InnoDB 缓冲池可能仍处于默认大小，没有利用 Linux 系统上的 RAM。如果你没有配置 MySQL 来使用它，那么你有多少 RAM 都没关系！

还有其他重要的调整参数。 MySQL 5.7 Performance Tuning Immediately After Installation 很好地介绍了最重要的调整选项。

索引可以大于表本身。接近 4 比 1 的系数是不寻常的，但不一定是坏的。这取决于您需要什么索引，除非您考虑需要针对这些数据运行的查询，否则无法知道这一点。

几年前我做了一个演示How to Design Indexes, Really（它与当前版本的 MySQL 一样相关）。这是视频：https://www.youtube.com/watch?v=ELR7-RdU9XU

【讨论】：

【解决方案2】：

这是您要检查的顺序：

1) 调整索引。选择一个常用的慢查询并分析它。了解 EXPLAIN ANALYZE 以便您可以判断您的查询是否正确使用了索引。完全有可能您的表没有正确索引，并且您长达数天的查询可能会在几分钟内运行。字面上地。如果没有适当的索引，您的查询将进行全表扫描以进行连接，并且有数十亿行，这将非常非常慢。

http://use-the-index-luke.com/ 是索引的一个很好的介绍，但是关于该主题的书籍和文章数不胜数。

1a) 对其他慢查询重复 #1。看看你能不能改进它们。如果您处理过许多慢速查询并且无法加快它们的速度，请继续进行服务器调优。

2) 调整您的服务器。 Bill Karwin 的链接在那里会很有帮助。

3) 着眼于增加硬件/RAM。这应该只是最后的手段。

花时间与#1 相处。它可能会带来最好的回报。您可以做很多事情来改进事情而无需花费一分钱。您还将学习如何编写更好的查询和创建更好的索引，并防止将来出现这些问题。

另外：听听比尔卡尔文和他的知识。他是专家，大写 E。

【讨论】：

【解决方案3】：

在对 600 个相当随机的表（其中一些比您的大得多）进行的调查中，您的 230GB:80GB 比率大约为 99%。请提供SHOW CREATE TABLE，以便我们讨论您是否“做错了什么”，或者这只是一种极端情况。（很少有 6 列索引可取。如果它是一个单个索引加起来高达 230GB，那就是“错误”。）

我看到较大的表在较小的机器上运行良好。如果您主要进行“点查询”，则实际上没有大小限制。如果您使用的是 UUID，那您就完蛋了。也就是说，它实际上取决于数据、查询、架构、月相、你的业力等。

交叉连接可以轻松完成一万亿件事情。带有 eq_ref 的连接通常不会比没有连接的查询慢多少。

“你无法通过调整自己的方式来解决性能问题。” “在性能问题上扔硬件要么浪费钱，要么延迟不可避免的事情。”相反，让我们看看“变慢的查询”，以及EXPLAIN SELECT ... 和SHOW CREATE TABLE。

这是一个数据仓库应用程序吗？有汇总表吗？

这是我的Cookbook on creating indexes。但是，如果您向我们展示您的代码，它可能会更快。

我可以提供另一个Tuning Analysis。

EXPLAIN SELECT ..... 是调查您的协助请求所需信息的关键部分。

为所涉及的每个表显示创建表也会有所帮助。

此时，用户可用的数据中两者都不可见......

【讨论】：

【解决方案4】：

我会尽力回答您的问题，但请记住，我不是 MySQL 专家。

1) 这是一个很大的数据库，有很大的表，但没有什么相当大的服务器无法处理。但这实际上取决于您的工作量。

2) 大于表本身的索引大小很有趣，但它可能是该表上所有索引的大小。在这种情况下是完全正常的。

3) 您的服务器中有 64 GB 的 RAM 意味着可能会有很多磁盘操作正在进行，它肯定会减慢您的速度。因此，添加一些内存肯定会有所帮助。也许在使用 iotop 运行查询时检查服务器的行为。并将其与来自顶部的信息进行比较，以查看服务器是否在磁盘上等待。

【讨论】：