刚接手一个电商项目的时候，我就被一个问题折腾得够呛——数据库动不动就断开连接。用户下单到一半，页面卡住，后台日志里全是“MySQL server has gone away”的错误。运维小哥蹲在机房查了三天，发现是连接池配置太随意，导致数据库压力一大就集体罢工。后来我花了点时间，用几个优化手段把连接池和查询策略重新调了一遍，结果性能直接翻了3倍，连接超时的问题基本绝迹。
第一个最容易被忽视的技巧是：给连接池设一个合理的“最大连接数”。很多开发者的习惯是越大越好，直接设成几百上千，但数据库服务器扛不住。MySQL在每个连接上都要分配内存和线程资源，连接数一多，CPU和内存就被吃光了，反而导致新连接创建失败或超时。我见过一个项目，连接池最大设成500，数据库只有4核8G，结果高峰期并发一上来，连接队列直接炸了。后来我根据服务器配置和业务峰值，把最大连接数降到150，同时把连接的“空闲超时”从默认的8小时调整到60秒，这样不用的连接能快速释放，性能反而翻了一倍。
第二个关键点是：用“连接复用”代替“频繁创建”。很多框架默认每次请求都新建一个数据库连接，用完就关，这看起来简单，但每次创建连接都要经过TCP三次握手、MySQL认证、权限检查，耗时轻松超过100毫秒。如果一个页面要调用5次数据库，光连接建立就占掉500毫秒，用户不卡才怪。我习惯用连接池工具，比如HikariCP或Druid，把连接创建好放在池子里，请求来了直接拿，用完了还回去。经过测试，复用连接能让单次请求的数据库耗时从200毫秒降到40毫秒，而且连接池还自带心跳检测，能自动踢掉断开的连接，避免僵尸连接堆积。
第三个容易被忽略的坑是：查询语句写得稀烂，拖死整个连接池。很多开发者在写SQL时，懒得加索引或者用SELECT ，结果数据库为了返回数据得全表扫描，占着连接不放，其他请求只能排队等着。我之前接手过一个订单查询接口，每查一次要跑2秒，连接池只有50个连接，结果20个请求同时进来，连接池就被占满，后面的请求全部超时。解决方案很简单：给频繁查询的字段加索引，把SELECT 改成只取需要的字段，再用EXPLAIN分析慢查询。改完之后，单次查询耗时从2秒降到30毫秒，连接池的压力瞬间卸掉了80%。
第四个技巧是：设置合理的“等待超时”和“重试机制”。很多项目默认的连接超时是30秒，这听起来很长，但在高并发场景下，30秒意味着连接池会被慢查询占满，新请求只能干等。我一般把连接超时设成3秒，如果3秒拿不到连接就直接报错，而不是让用户无限等待。同时，在业务代码里加上重试逻辑——如果第一次连接失败，等100毫秒再试一次，最多重试3次。这样既能避免慢查询拖垮系统，又能容忍短暂的网络抖动。我实测过，加了重试机制后，数据库偶尔闪断导致的错误率从5%降到了0.1%以下，用户体验基本不受影响。
第五个压轴技巧是：用读写分离分担主库压力。很多中小项目只用一个数据库实例，所有读写操作都怼到同一个连接上，结果主库一忙，所有请求都跟着慢。我一般在业务量起来之后，搭一个从库，把查询类的请求全部路由到从库，主库只负责写操作。连接池也分成主库池和从库池，各自独立配置。比如主库池设成100个连接，从库池设成300个，这样读请求再多也不影响写入。我经手的一个日活10万的项目，用了读写分离后，数据库连接超时问题直接归零，主库的CPU占用从90%降到30%，性能飙升了3倍不止。
写完这5个技巧，我想说的是：数据库连接超时这个坑，大多数时候不是MySQL本身的问题，而是我们没把连接池和查询策略当成一套系统工程来设计。真正的高手，不会等出事了再被动排查，而是从一开始就把连接池的容量、空闲超时、查询效率、重试机制和读写分离都规划好。这样一来，别说300%的性能提升，就算业务量再涨几倍，数据库也能稳稳扛住。下次再遇到“MySQL server has gone away”的报错，别急着怼运维或DBA，先看看自己的连接池是不是太随意了。
