数据库服务器内存容量规划的核心参考维度是并发连接数先算峰值并发连接，再算单连接内存占用，叠加缓冲池和系统预留，才能得出靠谱的内存配置。
数据库服务器内存容量规划：并发连接数才是第一参考指标
很多人在规划数据库服务器内存时,习惯先看数据量大小。数据量只是影响存储，并发连接才直接影响内存的爆发式消耗。 一个1TB的数据库，如果同时只有几十个连接，16GB内存可能富余；但一个100GB的数据库，如果并发连接冲到上千，32GB内存可能直接被吃光。
为什么并发连接对内存影响这么大？因为每一个数据库连接背后，都绑着一套完整的工作内存。
- MySQL里,每个连接是一条线程，需要分配排序缓冲、连接缓冲、临时表空间。
- PostgreSQL里,每个连接是一个独立进程，内存占用比线程模式更重。
- SQL Server里，每个连接对应一个调度任务，有自己的工作内存区间。
你多开一个连接,数据库就要多备一份工作内存，行业共识认为，单条连接的内存开销通常在2MB到20MB之间，具体取决于你开了多少会话变量、排序操作有多频繁、临时表用得多不多，看起来单条不多，但并发量从200涨到2000，光是连接本身就要吃掉几个GB。
而且这里面有个致命问题：内存是用峰值来算的，不是用平均值。 数据库连接数在一天里波动极大，白天可能几百，凌晨可能个位数，但你的内存买小了，高峰期就直接卡死，所以规划内存的第一步，是搞清楚你的数据库到底扛过多大的并发峰值。
数据库内存多大合适？先算峰值并发再定配置
你问数据库内存多大合适,没人能拍脑袋给你一个准数，但有个通用的推算路径。顺着并发连接数往下拆，一步步算，结果不会跑偏。
第一步,统计峰值并发连接数，别用平均值，用最高值，怎么看？MySQL里执行
SHOW STATUS LIKE 'Threads_connected'，找一天中数值最大的那段时间；PostgreSQL可以查pg_stat_activity的计数；有监控系统直接看曲线顶峰值，统计显示，大多数业务系统的峰值并发是日常均值的5到10倍，所以用平均值规划内存的人，基本都会翻车。
第二步,估算单连接内存开销，基础连接本身占2MB到5MB，排序和临时表操作另算。
- 单纯短查询,单连接3MB到8MB。
- 带有排序、分组、多表连接的查询，单连接10MB到20MB。
- 频繁使用临时表的业务,单连接20MB以上也不稀奇。
第三步,算缓冲池，MySQL的InnoDB缓冲池、PostgreSQL的shared_buffers、SQL Server的Buffer Pool，这部分是共享的，通常建议占总内存的50%到60%，比如你有32GB内存，缓冲池给到16GB到20GB是常见配置。
第四步,给系统预留，操作系统本身要留15%到20%的内存给文件缓存、内核、进程开销，这块不预留，连接一涨你连SSH都登不上。
举一个具体场景,一个小型电商平台，日常并发连接在300左右，大促秒杀能冲到1500，按单连接10MB算，1500个连接要15GB；缓冲池需要分到的内存，按数据量和热点数据量来定，假设需要20GB；系统预留再吃个15%到20%，这台数据库服务器的内存起码要配到40GB到48GB才算稳。
这么算完你会发现,并发连接数的权重比你想象的大得多。 数据量可以靠冷热分层、归档来压，但并发连接是硬需求，每个连接的内存你躲不掉。
单连接内存开销的隐藏大户
你以为连接只是占个线程的微量内存,其实真正的内存杀手是连接内部预分配的各类缓冲区，这些缓冲区在连接建立时就分配了，不管你用不用都占着。
- MySQL的
sort_buffer_size是每连接分配，默认256KB，设大了单个连接就能吃掉好几个MB。 join_buffer_size也是每连接分配，多表关联多的事务光这个就能吃几百MB。- PostgreSQL的
work_mem，一个带排序的查询可能同时用掉好几个work_mem的内存，连接数一多，内存瞬间爆掉。
所以在规划内存时,你得把这些缓冲区的大小也加进单连接开销里算，这也是为什么很多人买的机器配置不低，并发一上来就出现OOM（内存溢出）因为单连接内存开销被低估了。
mysql并发连接内存规划：一个典型的实战场景
拿最常见的MySQL来说,并发连接内存规划有几个典型坑。第一个坑是把max_connections设得很大，内存却跟不上。 你把max_connections设为2000，听起来像是给业务留了余量，但真到了2000并发时，内存不够用，MySQL会直接拒绝新连接或者触发OOM，业内专家指出，max_connections和innodb_buffer_pool_size必须联合调优，不能只看连接数或者只看缓冲池。
MySQL里更合理的顺序是：先估算连接内存，再看还剩多少给缓冲池。
假设服务器的总内存是64GB,系统预留留8GB，连接内存按1000并发、每个连接6MB来算，要吃掉6GB，那剩下的50GB可以给InnoDB缓冲池，如果并发限额要再往上提，你就得压缩单连接内存占用调小sort_buffer_size、减少joak_buffer_size、关闭不必要的预分配。
另一个常见误区是线程池和连接池混为一谈。连接池是应用侧的，线程池是数据库侧的。 应用层连上来1000个连接，如果没做连接池，数据库就得创建1000条线程；做了连接池，可能只有50条活跃连接在跑，内存占用瞬间从好几个GB降到几百MB，所以搞好连接池，相当于给内存做了一次大瘦身。
并发连接过高时，内存已经撑不住了怎么办
如果你的数据库服务器内存规划时没算准,现在并发连接一上来就内存吃紧，有几个立竿见影的办法。但这些办法有一个原则，先降连接，再谈加内存。
- 应用层全面接入数据库连接池,把空闲连接压到最低。
- 清理数据库端的长连接,设置
wait_timeout和interactive_timeout，把闲置连接踢掉。 - 拆分短连接和长连接业务,短查询走专门的连接池，批量任务单独分配连接数。
- 如果连接数降不下来,那就老老实实加内存，同时调大系统预留的Swap空间做兜底。
数据库服务器内存容量规划不是一次定死的事,业务增长、促销活动、接口变化，都能改变并发连接的量级，建议你每半年重新统计一次并发峰值的曲线，对照当前内存水位，提前预警。
Q&A：数据库服务器内存容量规划常见问题
并发连接数和CPU核数，对内存规划哪个影响更大？
并发连接数影响的是内存的下限,CPU核数影响的是并发处理能力的天花板。内存不够，连接直接被拒；CPU不够，连接都在排队，响应变慢但不会挂。 优先按并发连接数定内存，再按CPU核数评估能不能扛住处理负载，两者要同时看。
并发连接数在2000左右，数据库内存需要配置多大？
按单连接内存开销8MB到12MB来算,2000个连接需要16GB到24GB内存，再加上InnoDB缓冲池或shared_buffers，按总内存的50%到60%分配，系统预留15%到20%，整体服务器内存建议配置在64GB到96GB之间，具体看你的查询复杂度，排序和关联操作多的场景预算要往上提。
如何判断当前内存不足是并发连接太多导致的？
执行SHOW PROCESSLIST（MySQL）或查询pg_stat_activity（PostgreSQL），统计当前活跃连接数是不是已经接近或超过max_connections的设定值，再看系统的内存监控，如果内存使用率在高并发时段呈陡峭的线性增长，而连接数下降后内存立刻回落，基本可以判定是并发连接导致的，回想一下，连接数降下来后内存没恢复，那问题可能出在缓冲池设置或者内存泄漏上。