我的公司有一个分析师团队使用的mySQL服务器（通常一次3-4个）。最近，对于一个表格数量达10亿行（10 ^ 9条记录）的数据库，查询已经放慢了速度，有些甚至需要几天时间。
我们对微调一无所知，所以任何工具/经验法则都可以找出导致问题的原因或者至少缩小范围，这是值得欢迎的。
前往Workbench工作室＆gt;表格检查员我发现了我们最常用的数据库的这些关键值：
理想情况下，我想以最简单的方式微调服务器（更好），数据库（更糟糕）或两者（未来），以加快速度。
我的问题：
非常感谢。
答案 0 :(得分：5)
如果您正在管理这种规模的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答案 1 :(得分：3)
以下是您要检查的顺序：
1）调整索引。选择一个常用的慢查询并进行分析。了解EXPLAIN ANALYZE，以便您可以判断您的查询是否正确使用索引。您的表完全可能没有正确编制索引，并且您的日常查询可能会在几分钟内完成。从字面上看。如果没有适当的索引，您的查询将进行全表扫描以进行连接，并且数十亿行将会非常非常慢。
对索引的一个很好的介绍是http://use-the-index-luke.com/，但有关于该主题的书籍和文章数以万计。
1a）用其他慢查询重复＃1。看看你是否可以改进它们。如果您已经处理了许多慢速查询并且无法加速它们，那么请继续进行服务器调整。
2）调整你的服务器。 Bill Karwin的链接在那里很有帮助。
3）看看增加的硬件/ RAM。这应该是最后的手段。
花时间与＃1。这可能是最好的回报。你可以做很多事情来改善事情而不花一分钱。您还将学习如何编写更好的查询并创建更好的索引，并在将来防止这些问题。
另外：听听Bill Karwin和他的知识。他是资本E的专家。
答案 2 :(得分：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 .....是调查您的求助请求所需信息的重要组成部分。
为每个相关的表显示CREATE TABLE也会有所帮助。
此时，用户......的数据中均未显示......
答案 3 :(得分：1)
我会尝试回答你的问题，但请记住，我不是MySQL专家。
1）这是一个相当大的数据库，有大表，但没有相当大的服务器无法处理。但这实际上取决于你的工作量。
2）索引大小大于表本身很有意思，但它可能是该表上所有索引的大小。在那种情况下，这是完全正常的。
3）服务器中64 GB的RAM意味着可能会有大量磁盘操作正在进行，这肯定会让您失望。所以添加一些内存肯定会有所帮助。也许检查使用iotop运行查询时服务器的行为方式。并将其与顶部的信息进行比较，以查看服务器是否在磁盘上等待。