如果有8G的内存，应该如何优化服务器的MYSQL？ 现在连1G都没有用到，浪费呀！

按照下面的设置试试看：
key_buffer = 3840M
max_allowed_packet = 16M
table_cache = 1024
sort_buffer_size = 32M
read_buffer_size = 32M
read_rnd_buffer_size = 32M
myisam_sort_buffer_size = 256M
thread_cache_size = 32
query_cache_size = 256M
# Try number of CPU's2 for thread_concurrency
thread_concurrency = 8
其中key_buffer_size 上限是4G，不能再多了
但是实际的为了使MySql的性能最优化，内存的分配是需要进行调试的。建议你参考一下文章进行设置：
>假如你安装的是32位版本的win，mysqld使用最大内存为 2G（更改启动参数后为3G） 换成innodb表，并设置 innodb_buffer_pool_awe_mem_mb 或换64位的win200364位的mysql。 你的采纳是我前进的动力,记得好评和采纳，答题不易，互相帮助， 手机提问

数据锁死导致内存增加，这个是你程序设计的问题
解决比较麻烦，要分析，执行的所有 *** 作
检查在什么时间什么 *** 作后产生什么效果，这个和执行顺序也有关系
close只是你放开了链接而已

read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
这三项都是每个线程的内存分配量 就是说要是有100个用户 就要4M100+16M100+32M100=5200M 没有内存了。改小吧

如果我们查看“top”命令的输出，我们会看到：MySQL 57

MySQL 80

这也展示出 MySQL8 使用的更多常驻内存和虚拟内存。特别是“可怕的”虚拟内存，因为它远远超过这些 VM 上可用的 1GB 物理内存。当然，虚拟内存使用（VSZ）是现代应用程序实际内存需求的一个很差的指标，但它确实证实了更高的内存需求这个事。

实际上，正如我们从 “vmstat” 输出中所知道的那样，即使没有太多的“空间”，MySQL 8 和 MySQL 57 都不会在低负载下使用 swap 分区。如果您有多个连接或希望在同一个 VM 上运行某些应用程序，则可以使用 swap（如果未启用交换，则可能导致 OOM）。

这是一个有趣的实验，能看看我有多少可以驱动 MySQL 57 和 MySQL 8 的内存消耗。

innodb_buffer_pool_instances 参数，将 buffer pool 分成几个区，每个区用独立的锁保护，这样就减少了访问 buffer pool 时需要上锁的粒度，以提高性能。准备一个空数据库，在这里我们将 performance_schema_events_waits_history_long_size 调大，是为了让之后实验数据能采集的更多，在此不多做介绍。使用 sysbench，准备一些数据，

对数据进行预热 60s，可以看到预热期间的性能会不太稳定，预热后会比较稳定，

设置 performance_schema，这次我们将仅开启观察项（生产者）hash_table_locks，并开启 waits 相关收集端（消费者）。（相关介绍参看 实验 03）

为什么我们知道观察项应该选择 hash_table_locks？在 performance_schemasetup_instruments 表中，列出了所有观察项，但我们很难从中选出我们应观察哪个观察项。这时候，可以将所有观察项都启用，然后设计一些对比实验，比如使用几种不同的 SQL，观察这些 *** 作影响了哪些观察项，找到共性或者区。还有一种高效的方式是搜索别人的经验，或者阅读 MySQL 源码。本例中 hash_table_locks 隐藏的比较深，使用了阅读 MySQL 源码和对比试验结合的方法。

---