最近，我的系统与MySQL（技术上说是MariaDB）的连接不足。
我已将最大连接数设置为250（高于151）。但我对如何分配内存感到困惑。这台机器有32GB的内存，如果我正确地从mysqltuner读取结果。。。我只允许总共使用1GB。但在250个连接处*2.8米/螺纹时，它应该只能达到700米+全球328米？
看起来我们已经达到了7.55亿美元的峰值，但是我还有多余的记忆，我应该打开一些东西让MariaDB呼吸一下吗？
我读对了吗？
这台机器兼作apache&db服务器。
即使在完全倾斜的情况下，我也很少看到机器使用超过3或4GB的系统RAM
我运行了mysqltuner，下面是性能结果：
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 34d 1h 32m 42s (74M q [25.213 qps], 26M conn, TX: 46G, RX: 42G)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Physical Memory : 31.5G
[--] Max MySQL memory : 1.0G
[--] Other process memory: 647.4M
[--] Total buffers: 328.0M global + 2.8M per thread (250 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 755.5M (2.34% of installed RAM)
[OK] Maximum possible memory usage: 1.0G (3.20% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/74M)
[OK] Highest usage of available connections: 60% (152/250)
[OK] Aborted connections: 0.00% (2/26423553)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[OK] Query cache efficiency: 45.7% (21M cached / 47M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (541 temp sorts / 32K sorts)
[!!] Joins performed without indexes: 24537
[OK] Temporary tables created on disk: 1% (644 on disk / 51K total)
[OK] Thread cache hit rate: 98% (383K created / 26M connections)
[!!] Table cache hit rate: 0% (120 open / 36K opened)
[OK] Open file limit used: 0% (24/4K)
[OK] Table locks acquired immediately: 99% (5M immediate / 5M locks)
最佳答案
你必须明白MySQLtuner计算“最大MySQL内存”完全是胡说八道。
它基于理论上的最大值——只有当你最大限度地超出了cc>，然后每个连接在同一时刻运行一个查询时，每个查询都使用最大可能的排序缓冲区、读缓冲区和连接缓冲区。实际上，这在真正的服务器中永远不会发生。
当我在我支持的大多数生产数据库服务器上运行MySQLTuner时，“最大MySQL内存”被报告为服务器上实际物理RAM的数百倍。这不是问题，因为它是一个永远不会发生的理论上的最大值。
如果在数据库服务器上运行max_connections，即使所有150或250个线程都已连接，也只能看到6-8个线程在运行查询，而大多数其他线程都处于“休眠”状态。
这就像您使用SHOW PROCESSLIST登录到服务器，并且您的终端在shell提示符下准备就绪一样。你在执行命令吗？不，你的壳没用。但你仍然有联系。
MySQL也是如此。您的应用程序可能已连接到数据库，但您的应用程序尚未运行查询。甚至当它运行查询时，它可能不会使用允许的最大资源。然后它会很快完成并再次将连接返回到空闲状态。
在任何给定的时刻，连接的线程数可能很高，即使那些实际运行查询的连接很小。您可以比较：
mysql> show global status like 'Threads%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 510 |
| Threads_running | 13 |
+-------------------+-------+
以上是一个繁忙的生产MySQL实例中的典型数字。以我的经验，连接到运行线程的线程比率在10:1到100:1之间。
但是MySQLTuner的计算是不现实的-他们假设线程连接到运行线程的比率是1:1。
因此，您分配给MySQL的内存与您允许的
ssh无关。您可能会发现增加一些优化选项有助于提高性能，但这与数据的大小和针对该数据运行的查询类型有很大关系。
我建议阅读https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/
或者如果你想深入学习，请阅读：High Performance MySQL, 3rd Edition
关于mysql - 更改内存以提高MySQL性能-MySQLTuner，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/50823080/