如何降低“Created_tmp_disk_tables” - 在磁盘上创建的临时表计数？

Question

我有一个 ubuntu，mysql 5.6 DB，它被成千上万的用户大量使用。运行 10 天后，我有以下值：

| Created_tmp_disk_tables | 894170 |
| Created_tmp_files       | 26068  |
| Created_tmp_tables      | 914511 |

我的配置值是：

| tmp_table_size | 268435456 |
| max_heap_table_size | 1073741824 |

当我有 tmp_table_size = 16MB 和 max_heap_table_size=16MB 时，它是一样的。比我将其更改为 tmp_table_size = 256MB 和 max_heap_table_size = 1GB 但 Created_tmp_disk_tables 并没有停止增长。率是完全一样的。

我有 26GB 的堆。所有表都是 INNODB。

我错过了什么？

谢谢

Answer 1

“26GB 堆”是什么意思？

tmp_table_size = 256M危险地高。如果多个连接决定需要 tmp 表，则可能会耗尽 RAM。与降低各种设置相比，交换对性能的影响更差。

在许多情况下，Tmp 表是必需的。不要害怕他们。但一定要检查它们。

DISTINCT, GROUP BY,ORDER BY并且UNION通常需要一个 tmp 表。如果 tmp 表适合min(tmp_table_size, max_heap_table_size)，则 tmp 表可能在 RAM 中使用Engine=MEMORY. 如果大于该值，则 tmp 表Engine=MyISAM会变慢。使用 MyISAM 还有其他原因，最值得注意的是选择一个TEXT字段。 更多详情。

另一个常见的“错误”是盲目使用VARCHAR(255)和utf8。使用 MEMORY 时，它会变成 765 字节CHAR，这会加速到 MyISAM 的转换。

你给的数字...

• Created_tmp_disk_tables 几乎和 Created_tmp_tables 一样大——这意味着要么tmp_table_size不够大（我怀疑），要么 MEMORY 不能使用（我怀疑）。在我的分析中，高于 20% 是一个危险信号。
• Created_tmp_tables / Uptime -- 超过 20/秒是一个危险信号
• Created_tmp_disk_tables / Uptime -- 超过 1/second 是一个危险信号
• Created_tmp_disk_tables / Questions -- 超过 4% 是危险信号

设置 long_query_time = 1 并打开 SlowLog，最好是 FILE。等一天，然后在慢日志上使用 pt-query-digest 找到“最差”的查询。如果您不知道如何改进它们，请询问我们。

我不同意罗兰多的两点：

• RAM 磁盘是个坏主意——最好将额外的 RAM 分配给其他缓存，而不是试图超越 MySQL。
• OPTIMIZE TABLE 很少有用，并且与问题不太相关。

Answer 2

如果速率完全相同，则您需要进行一些查询或配置调整。为什么 ？

我之前讨论过调整tmp_table_size和max_heap_table_size

• Nov 25, 2014：在不添加索引的情况下提高性能（RAM 磁盘讨论）
• Feb 06, 2014：MariaDB：启动后 Created_tmp_disk_tables 高
• Apr 18, 2013：需要有关优化表的想法

您可能需要考虑增加join_buffer_size和sort_buffer_size（请参阅我的第二篇文章）