分析MySQL表会产生ERROR 1040 - 连接太多

时间:2011-03-14 16:20:33

标签: mysql mysql-error-1142 mysql-error-1040

为什么我跑步时

ANALYZE TABLE table_name_here

MySQL服务器开始发出此错误:

1040 - 连接太多

我通过PHPMyAdmin btw ..

运行

该表包含超过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内存。

1 个答案:

答案 0 :(得分:1)

我正在将评论转到完整答案。这是MySQL配置问题,您可以获得有关服务器故障的更好答案。

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

其次,ANALYZE TABLE,MyISAM表重建索引。这意味着MySQL尝试将整个表加载到内存中(或读取整个表)以重新构建索引。这会导致表锁定表并占用大量内存,这会干扰MySQL执行其他工作的能力(比如运行应用程序)。

我真正的建议是转移到InnoDB而不是MyISAM。它在管理内存,索引和数据方面做得更好。对于您正在处理的表格大小而言,它比MyISAM更快,并且减少了头痛。