MySQL 5.5虽然已停止官方维护，但在不少老项目中仍是主力，配置好它的核心在于my.ini文件、连接数、字符集三处，花10分钟调整就能让它在老服务器上稳定跑。
mysql5.5配置文件my.ini优化：这5个参数最关键
my.ini是MySQL 5.5的核心配置文件，Windows下位于安装目录根路径，Linux下叫my.cnf，路径一般在/etc/my.cnf，初次配置时,多数场景下我们只需要调整以下参数：
- max_connections：连接数上限，默认为100，如果业务并发较高，设置到500左右比较稳妥，但超过800会显著增加内存开销,在高并发与资源占用之间需要权衡。
- innodb_buffer_pool_size：InnoDB缓存池大小，官方建议区间在物理内存的一半到七成之间，比如8G内存的机器，配置4G到5G之间是合理范围，业内专家指出，这个参数对读写性能的影响最直接,调大它往往比调整其他参数带来的收益更明显。
- query_cache_size：查询缓存，MySQL 5.5版本中默认开启，但如果你发现写操作频繁，查询缓存不仅没用，还会因缓存失效锁争用拖慢整体性能，设置为0或较小值（如32M）反而更好。
- key_buffer_size：MyISAM引擎的索引缓冲区，若主要使用MyISAM表，可设为内存的两到三成，如果你用的是InnoDB引擎，保持8M到32M即可,设大了也是浪费。
- tmp_table_size：临时表大小，默认16M，排序或分组操作频繁时，调大到64M左右能有效减少临时表落盘超过该值MySQL会自动把内存临时表转为磁盘临时表，性能明显下降,这个坑很多老运维都踩过。
my.ini修改后必须检查的3个细节
改完参数不等于完事，不少人在重启MySQL后报错,多半是遗漏了下边几点：
- 参数值后必须带单位，如
256M，不能只写256，否则MySQL按字节解析,效果完全不是你想的那样。 - 配置项必须写在[mysqld]标签下，写在[client]或其他标签下会被静默忽略,根本不会生效。
- 保存文件注意编码，Windows下若用UTF-8保存带中文注释的my.ini，MySQL读取配置时会直接中断,服务起不来。
改完配置后，用mysqladmin -u root -p shutdown关闭服务再重启，比直接kill进程更安全,能避免配置文件未正常刷新的问题。
buffer_pool到底该设多大？分场景看
对于内存只有2G的小服务器，innodb_buffer_pool_size设置在512M到1G之间即可，留出足够内存给系统缓存和其他服务，内存充足但遇到磁盘I/O吃紧的情况，直接上调到物理内存六成以上，能立刻缓解读密集场景的瓶颈，如果数据库整体使用率不高，就不必追求过大缓存池，盲目调大反而会挤占系统内存，引发操作系统层的swap,在低配云服务器上尤其明显。
mysql5.5和5.7配置区别：升级前先看这几点
很多人在老项目迁移时纠结要不要从5.5升到5.7，两者在配置上差异不小,提前了解可以避免迁移后踩坑。
| 配置项 | MySQL 5.5 | MySQL 5.7 |
|---|---|---|
| 默认字符集 | latin1 | utf8mb4 |
| 默认排序规则 | latin1_swedish_ci | utf8mb4_general_ci |
| innodb_buffer_pool | 固定大小，需重启生效 | 可动态调整，默认128M |
| sql_mode | 默认宽松 | 默认严格模式 |
| 查询缓存 | 默认开启 | 默认关闭 |
行业共识认为，判断是否升级的核心指标不是新功能有多少，而是业务里有没有依赖MySQL 5.5旧语法的代码，比如5.5中允许的GROUP BY非完整列查询，到5.7严格模式下会直接报错；同样，5.5中常见的隐式字符集转换在5.7下也可能触发警告甚至失败。
从mysql5.5升级到5.7的配置迁移步骤
按顺序操作,尽量减少对线上业务的影响：
- 在5.5上执行
SHOW VARIABLES,把当前生效的变量值全部记录下来。 - 备份my.ini或my.cnf原文件，复制到独立目录留底,防止迁移失败后无法回退。
- 安装5.7后，用新版的默认配置作为基底，对比旧配置将自定义参数逐项迁移,不要直接整份覆盖。
- 特别留意
sql_mode，5.7默认包含STRICT_TRANS_TABLES，旧业务若存在宽泛的数据类型写入习惯，会频繁报错,需要逐步适配而非直接关闭严格模式。 - 执行
mysql_upgrade -u root -p，完成系统表和权限表升级,再确认所有实例启动正常。
mysql5.5配置windows环境变量：让命令行直接识别mysql
MySQL 5.5在Windows下的默认安装路径通常带版本号，比如
C:Program FilesMySQLMySQL Server 5.5bin，如果不配置环境变量，每次执行mysql命令都要写全路径，操作效率很低,跟着下面几步走就行：
- 右键”我的电脑”→”属性”→”高级系统设置”→”环境变量”。
- 在系统变量中找到
Path，点击编辑，在末尾追加;C:Program FilesMySQLMySQL Server 5.5bin，注意前面的分号是英文格式，路径用引号或直接追加均可,取决于系统版本。 - 新建系统变量
MYSQL_HOME，值设为C:Program FilesMySQLMySQL Server 5.5,这个变量后续在脚本中引用路径时会派上用场。 - 打开新CMD窗口，输入
mysql -u root -p,能正常提示输入密码即配置成功。
如果MySQL安装在了D盘或自定义目录，把上面路径替换成实际位置就行。安装路径中尽量避免中文和空格，否则部分命令行工具和脚本在解析路径时可能出问题，国内不少老机器上还残留着带中文路径的MySQL安装,出问题多半就是路径引起的。
环境变量配置完成后如何验证
打开命令行，依次执行mysql --version和mysqladmin -u root -p ping，能看到版本号输出和”mysqld is alive”的提示，说明环境变量已经生效，注意CMD窗口必须重新打开才能加载新的环境变量，在旧窗口里测试会提示”mysql不是内部或外部命令”,这是大家卡住最多的地方。
mysql5.5中文乱码问题：一条命令定位根因
中文乱码在MySQL 5.5中是高频问题，核心症结在于5默认字符集是latin1，本身不支持完整中文存储，好在解决方案不复杂,按顺序排查即可。
先执行SHOW VARIABLES LIKE '%character%'，看输出结果中character_set_server的值，如果显示latin1，就确认了乱码源头，多数情况下，业务库连接层、服务端、客户端三处字符集不一致都会引发乱码。
彻底解决mysql5.5配置中文乱码的完整方案
第一步，修改my.ini，在[mysqld]和[client]标签下分别加入配置。 [mysqld]部分：
character_set_server=utf8 collation_server=utf8_general_ci
[client]部分：
default-character-set=utf8
第二步，重启MySQL服务，再执行
SHOW VARIABLES LIKE '%character%'，确认所有值都变为utf8，如果某个值仍是latin1，说明对应位置的配置没生效,多半是写错了标签。
第三步，改字符集只影响新建和后续写入的数据，已经乱码的历史数据无法自动恢复，如果旧数据量不大，建议先导出,转码后再导入：
mysqldump -u root -p --default-character-set=latin1 database > backup.sql再使用iconv -f latin1 -t utf8 backup.sql > newbackup.sql完成转码，最后导入新库，如果只需要处理部分表，逐表导出导入更灵活，连接字符串中的字符集参数也要同步改成utf8，否则应用层写入时还是按latin1发送,乱码依旧。
mysql5.5配置常见问题解答
mysql5.5忘记root密码怎么跳过权限配置？
在my.ini的[mysqld]下临时加一行skip-grant-tables，重启MySQL后可免密登录，执行UPDATE mysql.user SET PASSWORD=PASSWORD('新密码') WHERE User='root'; 修改密码后，必须删除这行配置再重启，否则任何客户端都能无密码进入数据库，风险极高,尤其在对外开放的服务器上等同于裸奔。
mysql5.5启动后总是自动关闭，怎么办？
最常见的原因有两种：一是my.ini中的参数值超出系统资源限制，例如max_connections设置过大，导致内存不足；二是innodb_buffer_pool_size设置超过物理内存上限，操作系统触发OOM直接kill进程，先用tail -f查看MySQL错误日志（Linux默认在/var/lib/mysql下，Windows在data目录），定位到具体的错误行，按日志提示逐项回退检查参数即可，日志里通常直接标明哪个参数异常,不用靠猜。
mysql5.5能否直接用MySQL 5.7或8.0的配置参数？
不能，5.7和8.0引入了一些5.5不认识的参数项，比如innodb_buffer_pool_dump_at_shutdown、log_timestamps等，直接放进去启动时会报”unknown variable”并拒绝启动，社区版配置时沿用5.5原生参数集即可，不需要参考新版本模板，从5.7或8.0迁移回5.5属于极少数情况,这类兼容性问题暴露得更明显。
MySQL 5.5配置的复杂性不在参数数量，而在版本特定的行为方式和默认值，把my.ini、环境变量、字符集这三块理清楚,绝大部分运行问题都能提前规避。