MySQL数据库用得好好的，怎么突然就慢得像蜗牛爬？这事儿我太熟了。前阵子帮朋友调一个电商后台，数据量刚过百万，页面加载就要等上好几秒，老板急得团团转。后来我上手一看，索引没建好、查询语句写得粗糙、配置参数没调过——典型的“只管用不管养”。很多人以为MySQL装好就能一直快，其实不然，数据量一上来，那些偷懒的写法全要还债。今天我就把五个最实用的优化技巧掰开揉碎讲给你听，每个都是我实战中验证过、见效最快的。别嫌多，看完你就能让数据库跑得飞起。
第一个技巧，索引要精不要多。很多人一听说索引能加速，就给每个字段都加上索引。结果呢？写入变慢、磁盘空间暴涨，查询也没快多少。索引不是越多越好，而是得用在刀刃上。我见过最离谱的案例，一张表有20个字段，建了15个索引，但实际查询只用到了两个。那13个索引纯粹是累赘。正确的做法是，先找出你最常见的查询条件，比如WHERE、JOIN、ORDER BY后面的字段，给这些字段建索引。复合索引要遵循最左前缀原则，比如你经常查，那就建(a,b)的复合索引，别拆成两个单列索引。另外，索引字段要尽量短，用整型比用字符串好，用前缀索引比用全字段好。我习惯用查看查询计划，看看是不是走了索引，有没有全表扫描。如果看到或者特别大，那就说明索引设计有问题。记住一点，索引是给查询用的，不是给表用的，别为了“看起来专业”瞎建。
第二个技巧，查询语句一定别偷懒。我见过太多人写SQL跟写作文似的，SELECT 用得那叫一个顺手。但你知道SELECT 的代价有多大吗？它会读取所有字段的数据，哪怕你只需要两个字段。如果表有30个字段，其中几个还是TEXT或者BLOB类型，那一次查询就要读大量数据，IO开销直接拉满。正确的写法是，只取你需要的字段，比如。另外，避免在WHERE条件里用函数，比如，这会让索引失效。改成，索引就能用上。还有，LIKE查询别用前置通配符，也是索引杀手。实在需要模糊搜索，可以考虑用全文索引或者Elasticsearch。分页查询也别直接用OFFSET，数据量大了会越翻越慢。用主键或者索引列做分页标记，比如，比快得多。这些细节，改一个就能省下几毫秒，改十个就是几十毫秒，积少成多，效果惊人。
第三个技巧，表结构和数据类型要精打细算。很多人建表的时候图省事，字段类型全用VARCHAR(255)或者INT(11)，结果呢？数据量一大，存储和IO都扛不住。比如状态字段，用TINYINT就够了，0和1两个值，何必用INT？日期字段用DATE或者DATETIME，别用VARCHAR存，既浪费空间又没法做日期运算。我做过一个优化，把一个日志表的字段从VARCHAR(255)改成CHAR(2)，因为状态只有三个值，结果表大小直接减少了30%，查询速度也跟着提了一截。另外，字段尽量设置NOT NULL，因为NULL值在索引和查询中都需要特殊处理，影响性能。表结构还要考虑范式化和反范式化的平衡。范式化能减少数据冗余，但关联查询多了会慢；反范式化能减少JOIN，但更新数据容易不一致。我的建议是，读多写少的场景可以适当反范式化，比如把用户名字段冗余到订单表里，省去每次查订单都要关联用户表的开销。但写多读少的场景，还是规规矩矩用范式化，别给自己挖坑。
第四个技巧，配置参数别用默认值。MySQL安装完默认配置，那是为了兼容各种环境，不是为你量身定做的。我见过很多公司，服务器内存64GB，但innodbbufferpoolsize还是默认的128MB，等于让一个大胃王只吃一粒米。这个参数是InnoDB最重要的，建议设置为物理内存的70%-80%，但别超过80%，要给操作系统和其他进程留空间。比如服务器内存32GB，设成24GB就差不多了。另外，querycachesize在MySQL 8.0之后已经废弃了，如果你还在用5.7或者更早版本，这个参数要根据实际情况调整，别盲目开大，因为查询缓存失效时会有锁竞争。还有maxconnections，默认151对于小应用够用，但如果你的并发量高，比如几百个连接同时进来，就得调大一些，但别太大，不然内存撑不住。我习惯用和查看当前配置和运行状态，比如看连接数，看缓存命中率。如果命中率低于99%，说明buffer pool太小，得加内存或者调大参数。配置调优不是一次性的，要随着数据量和业务变化持续调整。
第五个技巧，死锁和慢查询要主动监控。很多人等到数据库卡死了才去排查，那时候已经晚了。我的习惯是，每天定时查看慢查询日志，把执行时间超过1秒的SQL抓出来分析。MySQL的slowquerylog默认是关闭的，你得手动打开，设置longquery_time为1秒，然后定期分析日志。工具可以用mysqldumpslow或者pt-query-digest，能帮你快速找到最耗时的查询。找到慢查询之后，用EXPLAIN分析执行计划，看看是不是走了全表扫描、有没有用到索引、排序是不是用了文件排序。另外，死锁也是常见问题，尤其在高并发写入的场景下。InnoDB的行锁机制虽然比表锁好，但如果事务处理不当，还是会死锁。比如两个事务互相等待对方释放锁，系统就会自动回滚其中一个。要避免死锁，尽量让事务短而快，别在一个事务里做太多操作；更新数据时固定顺序，比如总是先更新A表再更新B表；用查看最新的死锁信息，分析锁冲突的原因。主动监控比被动救火强一百倍，别等到用户投诉了才慌。
说一句，别指望一招鲜吃遍天。MySQL优化是系统工程，索引、查询、表结构、配置、监控，五环缺一不可。我见过太多人只调了索引，觉得万事大吉，结果查询快了但写入慢了，或者配置调大了但内存撑不住了。每个优化都要结合你的实际场景，先分析瓶颈在哪，再对症下药。比如你的业务是读多写少，那就重点优化索引和缓存；如果是写多读少，那就关注写入性能和锁竞争。别盲目照搬网上的配置模板，那可能不是给你用的。你可以在测试环境压一把，用sysbench或者tpcc-mysql模拟业务流量，看看改了之后效果怎么样。数据不会骗人，QPS上去了、响应时间降下来了，那就是真的有效。如果改了之后没变化，甚至更慢了，赶紧回滚，别硬撑。记住，优化的目的是让业务跑得更顺，不是让你变成参数调优专家。把时间花在刀刃上，先解决最痛的点，其他的慢慢来。你手里的MySQL，完全可以比你想象的快得多。
