MySQL服务器调优那些不太正经但实用的小技巧分享

“慢查询日志”别只看时间，看看是谁在“话痨” 大家都知道开慢查询日志找执行时间长的SQL，但有个歪招：别光盯着那些跑得慢的独行侠，更要看看那些“频繁刷屏”的语句，哪怕一条查询只慢0.1秒，如果一秒钟被执行200次，破坏力可能比一条10秒才跑一次的大查询还猛，有个来自某电商运维的经验：他们曾经通过慢查询日志的“出现频率”排序，而不是单纯按“查询时间”排序，逮住了一个被循环调用的、没有用上索引的简单查询，优化后整体负载直接下降一截，这招儿有点“以量取胜”的分析思路。

给连接数设个“弹性伸缩”的闹钟，别硬扛 调max_connections（最大连接数）不能只看硬件，一个野路子是：在业务低峰期（比如后半夜），故意把这个值调得很低，然后跑一遍你的核心业务功能，这时候很容易暴露出那些“忘了关连接”的代码bug，因为连接池很快会被这些“僵尸连接”耗光，问题立马现形，这是从一个开源社区讨论里学来的“压力测试”反串思路，调优前，先得确保你的应用不是“漏水的水池”。

索引不是银弹，试试“反着建” 通常都说，查询条件里字段的顺序要和索引顺序一致，但有个邪门技巧：当你的查询条件是个多选一（比如where status=1 or type=2），而且两个字段单独查询量都很大时，正经的建联合索引可能效果不好，这时候，可以试试分别给status和type建两个独立的索引，MySQL的优化器会聪明地使用“索引合并”策略，把两个索引的结果合并起来，速度可能比用一个笨重的联合索引更快，这个案例在Percona的博客里被提到过，算是利用优化器特性的一个“投机”方法。

内存分配：学会“欺软怕硬” 调内存参数（比如innodb_buffer_pool_size）时，教科书都说设为物理内存的70%-80%，但有个不正经但很实在的检查方法：在服务器上跑top命令，看看MySQL进程长期使用的实际物理内存（RES值），如果它远小于你设置的值，说明你设大了，内存被浪费了；如果系统频繁使用Swap（交换分区），那就是设小了，更野一点的路子是，在业务高峰时，通过命令show engine innodb status\G，看BUFFER POOL AND MEMORY部分里的Free buffers（空闲缓冲）是不是长期为0，如果是，说明缓冲池很吃紧，可以考虑在内存总量允许下“得寸进尺”地加大点,这招来自老DBA的实战观察。

用“笨”工具解决“聪明”问题 分析日志觉得麻烦？试试用最“土”的办法，把慢查询日志导出来，用Excel打开（先处理好格式），然后用数据透视表或者简单的排序、筛选，按出现次数、用户、客户端IP来分组统计，你可能会发现，某个特定的管理后台账号或者某个爬虫IP，才是制造大量慢查询的“真凶”，这种视觉化的、非技术工具的分析，往往能发现自动化工具忽略的“人”或“行为”模式的问题，这是很多运维在没用上高级监控工具前的“土法炼钢”妙招。

定期给表做做“碎片整理”，像收拾房间 尤其是对于频繁增删改的表（比如日志表、订单状态表），数据在磁盘上会变得七零八落（碎片化），虽然MySQL自己会处理一些，但久了还是会拖慢查询，可以定期（比如每月一次，在低峰期）对关键表执行一下OPTIMIZE TABLE 表名，这就像收拾杂乱的书桌，把文件重新摆整齐，找东西自然更快，但注意，这个过程会锁表，一定要在业务空闲时干，这个建议在《高性能MySQL》书里被比作“必要的家务”。

配置里藏个“减速带” 有个参数叫innodb_flush_log_at_trx_commit，它控制事务日志刷盘的激进程度，默认值1最安全，但每次提交都要刷盘，速度慢，对于一些可以容忍极少量数据丢失的非核心业务（比如用户操作日志、点击追踪），可以尝试把它设为2或0，这相当于在数据安全的高速公路上设了个“减速带”，能显著提升写入速度。但务必注意：这招是“用安全性换性能”，一定要和业务开发确认清楚，绝对不能用在核心交易、账户余额等数据上！ 这个技巧在阿里云的某些技术分享中被提及,用于特定场景。

终极歪招：重启大法 别笑，这是认真的，MySQL运行久了，尤其是内存管理、状态统计这些可能会有些“玄学”问题，一个计划外的复杂查询可能会“污染”缓存或优化器的判断，定期（比如每周或每两周，在维护窗口）优雅地重启一次MySQL实例（service mysql restart），能让一切状态归零，从头开始，很多莫名其妙的性能下降问题，一次重启后就消失了，这招被很多一线运维称为“包治百病的板蓝根”，虽然不优雅,但常常有效。