我干数据库这行快十年了，见过太多人一上来就调参数、加索引，忙活半天，瓶颈还在那儿杵着。说白了，优化这事儿，跟看病一个道理，你连病灶都没找到，开再多药也是白搭。今天我就把压箱底的那套实战打法掏出来，从怎么定位瓶颈，到怎么把性能榨到极致，一条龙讲清楚，全是踩过坑换来的干货。
先说定位瓶颈这步，很多人觉得难，其实就三板斧。第一板斧，看监控，别盯着CPU和内存傻看，那玩意儿虚得很。你得看等待事件，数据库自己会告诉你它卡在哪儿了，是等磁盘I/O，还是等锁，还是等网络。第二板斧，抓慢查询日志，但别眉毛胡子一把抓，重点看那些执行频率高、单次耗时长的，这俩一乘，才是真正吃性能的大户。第三板斧，用执行计划，explain一下，看它到底走了哪个索引，扫了多少行，有没有做排序和临时表。这三招下来，瓶颈基本就现原形了。
瓶颈找到了，接下来就是动刀子。我见过最冤的案例，一个查询慢得要死，结果是表里有个字段类型定义错了，存了数字却用varchar，导致索引全失效。这种问题，你调一百个参数都没用，改个类型立马起飞。所以优化第一原则，先看表结构和字段类型，别偷懒。然后才是索引，但索引也不是越多越好，每个索引都是写操作的负担。我的习惯是，给高频查询建联合索引，字段顺序按区分度从高到低排，区分度高的放前面，这样索引体积小，查询快。
说完索引，得聊聊SQL写法。很多人写的SQL，看着没毛病，实际上全是坑。比如在索引列上做函数运算，比如select * 一下捞一堆用不上的字段，再比如用前置通配符like '%xxx'，这些全是让索引失效的骚操作。我经常跟团队说，写SQL之前，先想想这查询要解决什么问题，用最直白的方式写出来，别炫技。有时候一条复杂的子查询，用join改写一下，性能能提升好几倍，前提是你得理解优化器是怎么工作的。
但话说回来，SQL和索引都优化到极致了，数据量一大，还是扛不住。这时候就得考虑架构层面的手段了。分库分表是终极方案，但代价也大，不是万不得已别轻易上。我一般先建议做读写分离，主库负责写，从库负责读，把读压力分散出去。要是还不行，再考虑引入缓存，把热点数据放到Redis里，数据库的QPS瞬间就能降下来一大截。记住，缓存是挡在数据库前面的第一道防线，能用缓存解决的，别让数据库硬扛。
还有一个容易被忽视的环节，连接管理。很多系统性能差，不是数据库不行，而是连接池配置有问题。连接开得太多，数据库光顾着维护连接了，没精力干活；开得太少，请求全堵在排队上。我的经验是，连接池大小设为CPU核心数的两倍左右，再加个合理的等待超时时间，这样既能保证并发，又不会把数据库拖垮。另外，一定要用连接池，别每次请求都新建连接，那开销大得吓人。
说到调优，不得不提参数配置。但我要泼盆冷水，网上那些所谓的“万能优化参数”，大多是扯淡。不同业务场景，参数配置天差地别。比如OLTP系统，追求的是低延迟，innodbbufferpool_size可以调大点，让数据尽量留在内存里；但OLAP系统，要的是高吞吐，可能得在排序缓冲区和临时表上多下功夫。我的建议是，别迷信什么最佳实践，拿你自己的业务场景去压测，用数据说话。
我得强调一个理念，性能优化不是一锤子买卖，是个持续迭代的过程。今天调好了，明天业务量上来了，又得重新来一遍。所以，每做完一次优化，一定要做基准测试，记录下优化前后的性能数据，形成自己的优化档案。下次再遇到类似问题，翻翻档案，直接对症下药，省时省力。
从瓶颈定位那三板斧，到SQL改写、索引设计，再到架构层面的读写分离和缓存，到连接池和参数调优，这一套组合拳打下来，不敢说能让你的数据库飞起来，但至少能让你从“瞎调”变成“会调”。记住，数据库性能优化这事儿，没有银弹，有的只是对细节的死磕和对原理的敬畏。把这套实战方法内化成自己的习惯，再遇到性能问题，你心里就有底了。
