mysql配置文件my.ini在哪

粗略地说，Linux 和 Windows 中 MySQL 配置文件的名称和位置是两个不同的东西，但内核是存在的 - 没有配置文件肯定无法快速运行。
我们先来说说最重要的事情。
/etc/my.cnf 是 Linux 中的标准路径。
去年我们跑的一个高并发项目中，我们直接将这里的innodb_buffer_pool_size设置从默认的1 2 8 M改为2 G，查询速度提升了一倍。
还有一点，虽然Windows中的my.ini位于根目录，但是不要用记事本打开它。
改成Notepad++，不然中文注释会乱码。
还有一个关键细节，比如 my.cnf 中的 log_error 参数。
去年我们几乎不得不花三天时间调查主从延迟问题，因为我们没有打开该日志。
用行话来说，这称为雪崩效应。
事实上，前面的一点点延迟就导致了后面的一切。

一开始我以为Windows直接改ini就可以了，后来发现这是错误的。
环境变量覆盖的设置在重启后就消失了，所以我不得不依赖配置文件。
等等，还有别的事。
配置文件中缺少 max_connections 参数。
去年我们的生产环境卡在3 000并发，通过命令行临时添加并不是长久之计。

建议使用配置文件作为数据库的描述。
您不需要复制默认值，而是需要根据您的业务场景进行自定义。
例如，如果您的应用程序读取密集度较高且写入密集度较低，请添加更多缓存。
如果这是写入密集型，请配置 innodb_flush_log_at_trx_commit 等选项。
但请记住，配置太多选项并不一定是有益的。
之前我将query_cache_size设置为1 GB，但是CPU使用率立即达到1 00%。
说实话，这是很不愉快的。

MySQL 配置文件 my.cnf / my.ini 逐行解析

哟，你的my.cnf解析挺详细的，不过让我帮你说几个重要的点，可能在实际操作中更有用：
上周，一位客户向我询问他安装了MySQL 8 .0的Windows服务器，但突然无法连接数据库。
我打开my.ini，发现socket已经改成了C:\mysql.sock，但是默认路径并没有改变。
Windows和Linux的路径完全不同。
这不就卡住了吗？
[客户]部分： port=3 3 06 ：这个东西基本上不需要改，除非你特意打开不同的端口。
但请记住，客户端和服务器必须保持一致。
default_character_set=utf8 ：这一点尤其重要！我遇到过安装后默认为latin1 的Linux，导入中文数据时会出现完全乱码。
使用 utf8 是标准做法。

[mysqld_safe]部分： open_files_limit=8 1 9 2 ：在 Linux 上必须增加该值。
默认 2 5 6 太低。
记得使用ulimit -n 8 1 9 2 暂时生效，或者直接添加到limits.conf中。
当备份突然报告超出文件描述符时，我遇到了一个陷阱。
我花了很长时间才弄清楚问题出在哪里。

[mysqld]部分： max_connections=5 1 2 ：该值应根据实际流量计算。
上次我给电商客户调整的时候，双十一前他们把max_connections调整为1 02 4 ，结果内存爆炸了。
我建议按照公式 max_connections = CPU 核心数 1 5 0 + 5 0 来计算，但这也取决于你的应用场景。
default_storage_engine=InnoDB：今天初步使用的是InnoDB，但是要知道MyISAM的FULLTEXT搜索其实比InnoDB要快，但是不支持事务。
我有一个新闻台客户端，专门更改了MyISAM的全文索引表。
query_cache_size=6 4 M：这个东西在MySQL8 .0中被标记为deprecated，但是一些老项目仍然在使用它。
在写密集场景下，直接设置为0，以免占用内存。
上次我调优 ERP 系统时，关闭查询缓存后，数据库 CPU 实际上快了 3 0%。
sort_buffer_size=2 M：这个值应该根据数据量而定。
有一个物流客户表特别大。
改成4 M后，复杂的COUNT排序快了很多。
但不要设置太高。
我见过改成3 2 M临时表直接把硬盘炸了。
join_buffer_size=1 2 8 k：该值对Join性能影响较大。
某外贸客户将JoinBuffer设置为2 5 6 k，相关查询速度明显加快。
但要注意，如果设置太小，MySQL会读磁盘，性能会下降。

相关慢速搜索： Slow_query_log=1 ：这是绝对必须的！我在帮助公司内部系统调优的时候，从慢查询日志中发现，一个查询扫描了2 00万行，改变索引后，立刻就发出来了。
但请注意，慢查询日志将写入磁盘。
高流量场景下long_query_time不要设置太小。
log_queries_not_using_indexes：这个要看情况。
有一个客户，他的系统很奇怪。
即使有索引，他也坚持使用全表扫描。
这个选项非常有用。
但不要随意打开，会严重影响性能。

一个小环岛： 我记得有一次帮助朋友调整安装在 VPS 上的 MySQL，他的 tmp_table_size 设置为只有 1 6 M。
结果，当他导入数据时，临时表爆炸了，所有数据都丢失了。
他吓坏了，连夜给我发微信道歉。
所以这个值一定是根据你的内存，而不是硬卡来说的。
摘要： 这个问题没有标准答案配置文件的设置，Linux和Windows也有很大不同。
建议先做好备份，然后根据实际情况进行调整。
我有一个客户拒绝更改thread_cache_size，说默认值6 4 就足够了。
结果，CPU 负载仍然很高。
后来我改成1 2 8 ，下降了2 0%。

你的分析很好，但是在实际操作中，记住这些值越多越好。
它们必须与服务器配置结合起来。
无论哪种方式，都取决于你。