Flask + SQLAlchemy连接池未充分利用，如何提升ClickHouse API吞吐量至400请求/秒？

看起来你现在的核心问题是连接池没被充分利用，而且虽然Mock接口能跑400QPS，但真实查询场景下Flask和ClickHouse的资源都没跑满，咱们一步步来排查优化：

一、先解决连接池配置与实际使用不匹配的问题 #

• SQLAlchemy连接池是进程独立的：你用了Gunicorn多worker（16个），每个worker都会维护自己独立的连接池，你配置的pool_size=150是单个worker的连接上限，不是全局总连接数。但你实际看到最多40个连接，说明每个worker的连接池都没用到多少，得先搞清楚为什么线程没去拿连接。
• 调大max_overflow参数：你当前设置的max_overflow=15太小了，当连接池的现有连接都被占用时，最多只能额外创建15个临时连接，这会直接限制峰值时的可用连接数。建议把这个值调大，比如设为100或者和pool_size持平，给连接池足够的弹性。
• 确认查询函数的连接使用逻辑：你的真实查询函数（对应mock的g1/g2）有没有正确从连接池获取并释放连接？比如有没有在函数里正确使用db.session，用完后有没有自动提交/回滚并关闭？如果出现连接泄漏（比如session没关闭），连接池里的连接会被占住，后续线程拿不到新连接，自然不会创建更多连接。

二、优化Gunicorn的Worker与线程配置 #

• 调整Worker类型和数量：Flask默认是同步Worker，对于IO密集型的数据库查询场景，同步Worker的并发能力有限。建议换成异步Worker，比如用gevent或者eventlet，启动Gunicorn时加上--worker-class=gevent，同时可以配合--worker-connections=1000来提升单Worker的并发处理能力。
• 平衡Worker和线程数：你当前用16个Worker+64个线程，再加上每个请求内部开4个线程，线程数可能过多导致上下文切换开销变大。可以试试：如果是4核CPU，设为8个Worker + 16个线程，同时去掉请求内部的ThreadPoolExecutor，改用异步查询（后面会说），减少线程嵌套的开销。

三、优化ClickHouse的连接与查询效率 #

• 确认驱动和连接方式：你用的SQLAlchemy连接ClickHouse，建议用官方的clickhouse-sqlalchemy驱动，并且优先用TCP接口连接（比HTTP接口性能高很多），TCP接口的并发处理能力更强，适合高QPS场景。
• 优化查询本身：虽然你说ClickHouse CPU只用了25%，但可能是查询的并行度没上去，或者查询本身有优化空间。比如：
  • 确认查询有没有用到分区、索引，避免全表扫描；
  • 对于批量查询，试试用ClickHouse的批量写入/查询语法，减少单次请求的交互开销；
  • 调整ClickHouse的max_concurrent_queries参数，确保它能承接足够的并行查询（你当前设的500是足够的，但要确认是否生效）。

四、完善连接池的监控与调试 #

• 增加连接等待日志：你当前的日志只监控了连接创建和回收，建议加上对连接等待的监控。SQLAlchemy的sqlalchemy.pool日志里，当线程等待连接时会有类似WaiterQueue waiting for connection的日志，通过这个可以判断是连接池不够用，还是根本没线程去请求连接。
• 排查连接泄漏：在每个查询函数里，打印当前连接的ID，或者用db.session.connection().connection_id()来追踪连接的使用情况，确认连接是否在查询结束后正确放回连接池。如果有连接泄漏，会导致连接池被占满，新请求拿不到连接。

五、考虑异步化改造 #

• 因为你的请求大部分时间都在等待数据库查询（IO等待），异步框架能更好地利用CPU资源，减少线程切换的开销。如果可以的话，把Flask换成FastAPI（支持原生异步），配合异步的ClickHouse驱动（比如async-clickhouse-driver），这样每个请求不需要开线程，而是用协程处理，能支持更高的并发量。即使不换框架，也可以用Flask-Async扩展来实现异步视图。

备注：内容来源于stack exchange，提问作者Abhilash Gopalakrishna