前几天跟一个做后端的朋友聊天，他说公司数据库最近老是慢得像蜗牛，查个用户订单要等好几秒，老板急得直拍桌子。我说你检查索引了吗？他说索引都建了。我又问慢查询日志开了没？他愣了一下，说没注意这个。这其实不是个例，很多人觉得MySQL装上去能跑就行，但真正用起来，坑一个接一个。数据库这东西，平时不显山露水，一旦出问题，那就是整个系统的瓶颈。
先说索引的事儿。很多人觉得索引越多越好，恨不得每个字段都加一个，结果写数据的时候慢得想哭。索引的本质是拿空间换时间，但每次插入、更新、删除，索引都得同步维护。你想想，一张表十个索引，写一条记录就要更新十棵树，不慢才怪。我见过最夸张的例子，有人给一个日志表建了八个索引，结果每天写入几百万条数据时，数据库直接卡死。正确做法是只给经常出现在WHERE、JOIN、ORDER BY后面的字段加索引，而且要注意区分度。比如性别字段只有男女两种值，加索引几乎没用，因为扫描一半数据跟全表扫描没区别。复合索引更讲究，最左前缀原则得记住，把最常查询的字段放前面。
再说说慢查询日志，这玩意儿简直是数据库的体检报告。很多人觉得服务器跑得好好的就没事，但慢查询日志能告诉你哪个SQL在偷偷拖后腿。我有个习惯，上线新功能后，一定先把慢查询日志打开，设置个阈值，比如1秒，然后定期分析。有一次排查一个报表页面加载要20秒的问题，打开慢查询日志一看，有个SQL用了临时文件排序，数据量几十万行，直接内存不够用，全写到磁盘上了。加了个合适的联合索引，查询时间从20秒降到0.3秒。这个案例说明，没有日志你永远靠猜，有了日志你才有证据。可以用pt-query-digest这种工具来分析慢查询日志，它会自动把相似的SQL聚合起来，告诉你哪些是真正需要优化的。
连接数管理也是个容易被忽视的点。很多应用框架默认开一堆连接池，但MySQL的最大连接数就那么点。我见过一个场景，微服务架构下，每个服务都开30个连接，八个服务就240个，而MySQL默认最大连接数才151，结果服务一启动就报Too many connections。解决办法不是简单调大最大连接数，而是要从应用层面控制。连接池的大小要根据业务并发量计算，不是越大越好。一般来说，核心业务线给个50到100个连接够用了，其他非核心业务共享一个连接池。另外，记得开启waittimeout和interactivetimeout，让长时间空闲的连接自动断开，不然连接池会越积越多。还可以用ProxySQL这种中间件来做连接池管理，它能控制前端连接数，还能做读写分离。
备份策略这事，说起来简单做起来难。很多人觉得每天半夜跑个mysqldump就万事大吉，但真到恢复的时候才发现各种问题。比如备份文件太大，恢复要十几个小时，业务等不起。或者备份时没锁表，数据不一致，恢复出来对不上账。我建议至少做三件事：一是定期做全量备份，比如每周日晚上；二是每天做增量备份，用binlog来补；三是每个月做一次恢复演练，确保备份文件真的能用。备份工具推荐用XtraBackup，它支持在线热备，不锁表，速度还快。另外，备份文件一定要存到异地，万一机房着火或者硬盘坏了，本地备份也跟着没了，那就真叫天天不应了。
SQL语句的写法更是直接关系性能。很多人写SQL只求能跑出结果，不管执行计划。比如SELECT *，你查十个字段可能只需要两个，但MySQL得把所有字段都读出来，浪费IO。再比如在WHERE条件里对索引字段做函数操作，像WHERE DATE(createtime) = '2024-01-01'，这样索引就失效了，得改成WHERE createtime >= '2024-01-01' AND createtime < '2024-01-02'。还有一种常见问题，就是关联查询时用小表驱动大表。比如两张表关联，一张一万行，一张一百万行，应该把一万行的表作为驱动表，这样关联次数少。用EXPLAIN命令看一眼执行计划，有没有用到索引、扫描了多少行、有没有临时表，这些都一目了然。我习惯写完SQL后随手跑个EXPLAIN，就像写代码前先画个流程图一样自然。
事务隔离级别和锁机制也得心里有数。MySQL默认是REPEATABLE READ，但很多业务场景其实用READ COMMITTED就够，还能减少间隙锁，提升并发性能。我遇到过一个死锁问题，两个事务同时更新同一条记录，都先读后写，结果互相等锁，死锁。排查发现是事务里先SELECT再UPDATE，而且没有按固定顺序操作。解决办法是把更新操作尽量放到事务开头，或者用SELECT ... FOR UPDATE加锁。另外，长事务是数据库的噩梦，一个事务跑几分钟，会导致undo log膨胀，binlog堆积，甚至影响主从同步。写代码时记得控制事务粒度，该提交就提交，别在一个事务里做一堆耗时操作。
说说参数调优。很多人觉得MySQL装好就不动了，但默认参数是为小网站设计的，生产环境根本不够用。比如innodbbufferpoolsize，默认才128M，但InnoDB的数据和索引都放在这个缓冲池里，太小了就会频繁刷盘。一般建议设为物理内存的70%到80%，但要留出一部分给操作系统和连接。还有innodblogfilesize，默认48M，对于写密集型业务，日志文件太小会导致频繁checkpoint，影响性能。我一般设到1G左右，具体要看业务写入量。sortbuffersize和joinbuffer_size也别乱设，每个连接都会分配一份，设太大容易撑爆内存。这些参数不是一次性调好的，得结合监控数据慢慢试，比如用Percona Toolkit的pt-mysql-summary和pt-variable-advisor来检查参数是否合理。
说到底，MySQL优化不是一锤子买卖，而是持续的过程。业务在变，数据量在涨，查询模式也在变，今天优化的方案可能三个月后就不适用了。关键是要养成习惯：上线前先做压测，运行中开慢查询日志，定期分析执行计划，遇到慢查询不急着加索引，先看是不是SQL写得有问题。数据库这玩意儿，你尊重它，它就给你好好干活；你糊弄它，它就让你加班到深夜。
