你打开MySQL慢查询日志，看到那个跑了整整3秒的SQL，心里咯噔一下。别慌，这很正常。MySQL优化这事儿，说难不难，说简单也不简单。关键是得掌握正确的思路，不能一上来就想着调参数、改配置。我见过太多人，数据库慢得像老牛拉车，第一反应就是去翻配置文件，把innodbbufferpoolsize翻个倍，结果该慢还是慢。数据库优化的核心，永远是先从SQL和索引入手，这是性价比最高的切入点。
想想看，一条SQL慢，最直接的原因是什么？要么是扫描了太多数据，要么是锁等待太久。扫描数据太多，十有八九是索引没用好。就说最常见的查询场景，你要从百万行数据里找某个用户的订单，如果userid上没有索引，MySQL就老老实实全表扫描。全表扫描意味着什么？意味着它要把每一行都读一遍，哪怕你只要10条记录。这时候加个索引，效果立竿见影。但索引也不是越多越好，每个索引都会拖慢写入速度，占用额外空间。这就是优化里的第一个平衡点。
索引设计这块，有个细节很多人容易忽略：复合索引的字段顺序。假设你有个表记录用户的订单，查询条件是userid加上createtime范围查询。很多人会先给userid建索引，再把createtime加进去。但如果你把createtime放在前面，userid放后面，那这个索引对userid查询就基本失效了。因为MySQL在复合索引里，只有最左前缀才能用到索引。这个规则听着简单，实际踩坑的人一抓一大把。我建议你写SQL前，先想想查询条件里哪些字段是等值匹配，哪些是范围匹配，等值的放前面，范围的放后面。
说完了索引，再说说SQL本身。有些写法天生就是性能杀手，比如在WHERE条件里对索引字段做函数操作。SELECT FROM orders WHERE DATE(createtime) = '2024-01-01'，这个写法看着很自然，但MySQL没法用createtime上的索引，因为你把它包在DATE函数里了。正确的做法是写成createtime >= '2024-01-01' AND createtime < '2024-01-02'，直接让索引生效。类似的坑还有隐式类型转换，比如把字符串字段和数字做比较，MySQL会偷偷把字段转成数字，索引又废了。
表结构设计这块，很多人觉得跟优化没关系，其实关系大了。字段类型选不对，索引用起来就费劲。比如存手机号，用VARCHAR(11)就够了，但有人非要给VARCHAR(255)，MySQL读索引时就要多读很多字节。再比如日期字段，用DATETIME还是TIMESTAMP，区别不小。TIMESTAMP只占4字节，能存到2038年，适合记录创建时间。DATETIME占8字节，但范围大得多。选哪个，得看你的业务场景。还有一点，能用数字就别用字符串，数字比较比字符串快得多，索引也小得多。
连接查询这块，优化空间也很大。很多人写JOIN，喜欢用小表驱动大表，这个思路没错。但更关键的是，被驱动表的连接字段上必须有索引，不然MySQL得全表扫描去匹配，性能直接崩掉。我见过一个案例，A表1000行，B表1000万行，连接字段上没索引，一次JOIN跑了10分钟。加了索引，0.1秒就出结果。还有，能用INNER JOIN就别用OUTER JOIN，后者处理NULL值很麻烦，MySQL经常要额外扫描。如果确实需要LEFT JOIN，确保右表的连接字段有唯一索引。
分页查询也是常见痛点。LIMIT 100, 20这种写法，MySQL得先把前100万行全部读出来，再扔掉前100万行，只取20行。数据量一大，CPU和IO都扛不住。优化思路是用游标分页，比如记录上一页最后一条的ID，然后WHERE id > 上一个ID LIMIT 20。这样MySQL就能直接走索引，不用扫描无关数据。另一种方案是子查询，SELECT FROM table WHERE id >= (SELECT id FROM table ORDER BY id LIMIT 100, 1) LIMIT 20，也能绕过这个坑。
说到锁，MySQL的锁机制对性能影响很大。InnoDB的行锁，看着很美好，但如果你没用到索引，行锁会升级成表锁。比如UPDATE操作，如果WHERE条件上的字段没有索引，MySQL就全表扫描，每一行都加锁，跟表锁没区别。这时候并发一上来，其他事务全堵在锁上。解决办法很简单，确保UPDATE和DELETE的WHERE条件都能走索引。还有，长事务也是性能杀手，一个事务跑太久，持有锁的时间太长，后面排队的事务越来越多，系统吞吐量直线下降。
缓存这块，MySQL本身有查询缓存，但8.0版本已经移除了，因为在高并发场景下反而拖慢性能。替代方案是业务层缓存，比如Redis或Memcached。把热点数据的查询结果缓存起来，能大幅减少数据库压力。但缓存也有坑，比如缓存穿透、缓存雪崩、缓存击穿，每个都需要针对性地处理。最简单的做法是设置合理的过期时间，加上布隆过滤器拦截非法请求。另一个思路是使用读写分离，主库负责写，从库负责读，分摊压力。
说下参数调优。很多人一上来就调参数，其实参数调优是最后一步。你得先确保SQL、索引、表结构都没问题，再来调参数。innodbbufferpoolsize，这个参数很关键，一般建议设为物理内存的70%左右。但如果你的数据量远小于这个值，设太大反而浪费。还有logfilesize，太小会导致频繁刷盘，太大又占用内存。我的建议是先跑一段时间业务，用SHOW ENGINE INNODB STATUS观察日志写入频率，再决定调多大。MySQL优化不是一锤子买卖，而是一个持续迭代的过程，每次改动都要有数据支撑。
