这里分享一下个人的一点认识，不足之处欢迎大家拍砖并补充。仅仅是根据问题是无法直接给出准确的答案的，我相信谁也不敢直接给你下定义去估算一台数据库服务器能够承受的并发量是多少。即使给出了，也无法确保是否有预料之外的情况发生。
比如你是为了预估已有系统的的容量和并发瓶颈，还是做新项目的技术选型。另外还需要一系列的基础数据支撑，才能更好地做出并发估算。下面咱们一起讨论一下，如何做技术选型：内在因素在估算之前我们必须清楚这台数据库服务器的配置是什么情况，正常情况下我们需要摸清楚以下几点因素：什么数据库？是MySQL还是Oracle亦或是DB2、PostgreSQL等；几核CPU？现代数据库应用都充分地运用了多核CPU的并行处理能力；内存多大？数据库的索引数据、缓存数据都会进入内存中；磁盘IO能力：数据库文件都存储在磁盘中，所以磁盘的IO能力将是影响数据库性能的最直接因素；网络带宽：网络的上行和下行带宽，数据库服务器可支持的最大连接数是多少。
外在因素“天下武功，唯快不破”。应用程序开发如此，SQL查询、操作也是如此。更快意味着服务器资源的快速释放，以便CPU能继续处理其他的任务请求。我们在评估数据库的并发量的时候，即使数据库服务器性能再好，你做出的评估如果没有结合使用数据库的程序的话，那也是属于纸上谈兵。结合以下实际情况，可以更准确安全的做数据库并发量评估或技术选型：连接数据库的都有哪些程序？
给APP用和给大数据团队做数据报表分析用完全是两码事；业务数据量多大？最大的表能达到多少？是否需要分库？分表？平均SQL执行时间多大？业务程序总PV能达到多少，每天什么时间段是高峰期，高峰期持续多久？可以根据高峰期QPS来预估数据库要承受的并发量，在此基础上再做2倍、3倍的扩容，防止突然来的高流量冲击。最好的办法是做压力测试上面说的是数据库服务器的并发量预估考虑的内在因素和外在因素，根据这些因素我们便能预估出一台服务器需要承受的并发量是多大了。但是仅仅是预估，无法达到一个准确的数字，或者说这台数据库服务器最大能承受的并发量是多少也是无法知道的。
所以最好的办法是做数据库压力测试，压力测试的时候，我们可以一点一点的加压力，逐步的得出数据库的：QPS：QueriesPerSecond每秒处理的查询数（如果是数据库，就相当于读取）TPS：TransactionsPerSecond每秒处理的事务数(如果是数据库，就相当于写入、修改)IOPS：每秒磁盘进行的I/O操作次数得出这些数据，便能做到心中有数，也能准确地判断出能否支撑住接入的程序和业务。常用的压测工具：sysbenchTpcc-mysqlmysqlslap如何使用的问题大家可以google一下，也可以使用这些工具实验一下。
没有固定的公式去计算服务器的并发量，即使相同配置下的不同服务器，也无法做到相同水平的处理能力，必须结合服务器自身的情况和业务的具体情况做大致的预估，并最终进行全场景业务压力测试来确定具体并发数值。