连接池，撑不住高并发？
这是一个非常经典的技术误区，很多开发者认为“并发高了，把连接池调大不就行了吗？”。但现实往往是：连接池越大，数据库死得越快。
数据库连接池之所以“撑不住”高并发，核心矛盾不在于“连接数”本身，而在于底层硬件资源的瓶颈与软件管理的开销。
连接池的职责是：重用连接 + 限制最大连接数，避免每个请求都新建/销毁连接的巨大开销。
高并发场景下，所有业务线程会来抢池里的有限连接：
抢不到就排队，应用响应变慢，看起来像“撑不住”；
盲目把 pool size 调大，短期访问变快，但 DB 端连接数飙升、资源争用更严重，整体反而更不稳。
直观比喻：连接池像餐厅里有限的桌子，高并发时排队是正常现象。
你增加桌子到塞满整条街，不会提高出菜速度，只会把厨房搞崩。
如何来应对高并发？
如果连接池本身不是银弹，面对百万并发我们该怎么办？
异步化处理 (MQ)： 并不是所有请求都要实时写入数据库。
利用消息队列（如 Kafka/RocketMQ）削峰填谷，让数据库按自己的节奏慢慢处理。
读写分离： 增加从库（Slave），将占 80% 流量的查询请求分摊出去，减轻主库压力。
缓存（Redis）： 在请求到达数据库之前，用缓存拦截掉绝大部分的重复查询。
分库分表： 单机数据库的连接数和硬件有上限，通过物理拆分，将压力分散到多个数据库节点上。
连接池调优： * Minimum Idle = Maximum Pool Size：避免连接频繁创建和销毁的开销。
设置合理的超时时间：宁可报错（快速失败），也不要让请求一直卡着浪费资源。