分析 MySQL 表给出 ERROR 1040 - Too many connections

Posted 2023-02-24

【中文标题】分析 MySQL 表给出 ERROR 1040 - Too many connections

【英文标题】：Analyzing a MySQL table gives ERROR 1040 - Too many connections

【发布时间】：2011-07-15 03:42:29

【问题描述】：

为什么我跑的时候会这样

ANALYZE TABLE table_name_here

mysql 服务器开始发出此错误：

1040 - 连接过多

我已经通过 phpMyAdmin 运行了这个。

该表包含超过 1500 万行数据。有没有办法解决这个问题？

MySQLTuner 结果：

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.91-rs-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB +Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 10G (Tables: 192)
[!!] Total fragmented tables: 14

-------- Security Recommendations  -------------------------------------------
ERROR 1142 (42000) at line 1: SELECT command denied
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 21m 37s (134K q [103.756 qps], 982 conn, TX: 267M, RX: 20M)
[--] Reads / Writes: 88% / 12%
[--] Total buffers: 1.2G global + 22.2M per thread (120 max threads)
[!!] Maximum possible memory usage: 3.8G (99% of installed RAM)
[OK] Slow queries: 0% (4/134K)
[OK] Highest usage of available connections: 14% (17/120)
[OK] Key buffer size / total MyISAM indexes: 1.0G/2.9G
[OK] Key buffer hit rate: 97.7% (1M cached / 25K reads)
[OK] Query cache efficiency: 72.7% (92K cached / 127K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)
[!!] Joins performed without indexes: 492
[!!] Temporary tables created on disk: 44% (490 on disk / 1K total)
[OK] Thread cache hit rate: 98% (17 created / 982 connections)
[OK] Table cache hit rate: 97% (262 open / 268 opened)
[OK] Open file limit used: 0% (463/65K)
[OK] Table locks acquired immediately: 99% (78K immediate / 78K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 10.0M, or always use indexes with joins)
    tmp_table_size (> 192M)
    max_heap_table_size (> 192M)

最初我的密钥缓冲区大小仅设置为 64MB。当我将密钥缓冲区大小设置为 1GB 时，我的最大连接用户数在运行该命令时仅达到 17 个峰值。当它只设置为 64MB 时，它总是达到允许的最大连接用户数。我无法将其设置为更高，因为我的服务器仅限于 4GB 内存。

【问题讨论】：

rackerhacker.com/2008/06/24/… - 这是一个配置问题，不一定与分析表相关。运行分析会锁定连接，如果您的运行接近配置的限制，您将看到此问题。

我已经添加了 MySQLTuner 结果，我做了一些更改，当我运行该命令时不再出现“连接太多”错误，但我得到 MySQL 最大内存使用量是危险的高消息。我认为这与索引太大的表有关。无论如何要解决这个问题？

【参考方案1】：

我将我的评论移至此处的完整答案。这是一个 MySQL 配置问题，您可能会在服务器故障上得到更好的答案。

ANALYZE TABLE 做了两件事会导致您的服务器出现问题。首先是它是一个需要很长时间才能运行的命令。从您对问题的过于简短的描述中，我猜想您的应用程序正在与数据库进行很多短连接。由于 ANALYZE 需要很长时间，因此运行时使用的连接被锁定。如果应用程序正在使用连接池或对其可以建立的连接数有特定的应用程序限制，我会将其设置为比 MySQL 连接限制少 3 个，以允许您执行这样的工作。

第二个，ANALYZE TABLE，为 MyISAM 表重建索引。这意味着 MySQL 尝试将整个表加载到内存中（或读取整个表）以重新构建索引。这会针对表发出表锁并占用大量内存，这会干扰 MySQL 执行其他工作的能力（例如运行您的应用程序）。

我真正的建议是迁移到 InnoDB 而不是 MyISAM。它在管理内存、索引和数据方面做得更好。对于您正在处理的表格大小，它比 MyISAM 更快，并且更少令人头疼。