配置优化的三个反模式：都是用通用经验替代对系统的理解

给MySQL做配置优化时，最容易踩的坑不是”某个参数该设成多少”，而是依赖 几种看起来很有道理、实际经不起推敲的通用做法：第一是”按命中率调优”—— 一条常见经验法则是”键缓存命中率应该高于某个百分比，太低就加大缓存”， 但缓存命中率本质上取决于工作负载本身（有些工作负载不管缓存开多大都 不可缓存），缓存太小时确实可能表现为命中率低、加大缓存后命中率也确实 可能回升，但这只是相关性、不是因果关系——命中率本身不能直接告诉你 缓存大小是否合适，只是恰好在某些场景下两者同时变化，让人误以为存在 稳定的因果链条。第二是直接套用网上流传的”调优脚本”或博客建议——这类 脚本把未经系统性验证的经验法则打包固化，会把”依据具体工作负载判断”这 件事偷换成”套一套通用公式”，而”调优”这个词本身也容易暗示”随便改改看 效果”这种缺乏纪律的做法，更贴切的说法应该是”配置”或”优化”（基于对内核 行为的理解，有依据地调整）。第三是迷信”内存消耗公式”（包括MySQL崩溃 时自己打印出的那个公式）——MySQL并不是一个严格控制自身内存分配上限 的数据库，随手写一段不断创建大变量的SQL就能把服务器内存耗尽到崩溃， 这说明任何试图用一个固定公式算出”MySQL最多用多少内存”的尝试，从 架构上就注定不可靠。这三种反模式的共同根源是同一个：把在别处观察到的 相关性/经验规则，当成放之四海而皆准的因果规律，直接套用到当前系统上， 而跳过了本该做的”先理解这台具体服务器的工作负载和内核行为，再据此判断” 这一步。