可通过engine.pool.checked_out()和engine.pool.checked_in()获取当前借出与空闲连接数，二者之和反映实时使用状态；需结合select 1执行检测真实可用性，并监控checked_out持续上升以定位连接泄漏。
查连接池当前使用量：用 pool.checked_in() 和 pool.checked_out()
SQLAlchemy 的连接池本身不直接暴露“已用/空闲数”的属性，但可以通过底层 Pool 对象的统计方法拿到。关键不是看 engine.pool.size（那是最大连接数），而是实时状态。
常见错误是以为 engine.pool.checkedout() 存在——它不存在，正确方法是先获取池实例再调用：
-
from sqlalchemy import create_engine后，engine.pool.checked_out()返回当前被借出的连接数 -
engine.pool.checked_in()返回当前归还并处于空闲队列中的连接数 - 二者之和可能小于
pool.size（比如有连接被丢弃或未归还） - 注意：这些方法只在使用
QueuePool（默认）时有效；若用了NullPool，所有值恒为 0
检测连接是否真实可用：别只靠 ping，要 execute("SELECT 1")
很多监控脚本用 engine.execute("SELECT 1") 或 connection.ping() 判断连通性，但 ping() 在 MySQL-Connector/Python 或 PyMySQL 中行为不一致，且对 PostgreSQL / SQLite 无效。
真正可靠的写法是：从池里拿一个连接，执行轻量查询，再显式归还：
- 用
with engine.connect() as conn:自动归还，但会占用一次 checkout 计数 - 更轻量的是
conn = engine.pool.connect(); conn.execute("SELECT 1"); conn.close()，避免事务上下文开销 - 如果查询抛出
OperationalError或DatabaseError，说明连接失效，需触发告警 - 别在应用主线程高频轮询——建议每 30 秒一次，否则可能拖慢池内连接复用
连接泄漏怎么定位：看 pool.checked_out() 持续上涨 + 日志里没 close()
连接池用着用着就卡住、新请求超时，大概率是连接没归还。典型现象是 pool.checked_out() 数值随时间单调上升，且长期不回落。
原因往往藏在异常路径里：
- 用了
connection = engine.connect()却没包在try/finally里调用connection.close() - 异步代码中混用同步
Connection，await 缺失导致 close 被跳过 - ORM 查询后对
result.fetchall()结果做了耗时处理，期间连接被其他协程抢占（尤其在 asyncio + SQLAlchemy 2.0+ 场景） - 开启
echo_pool="debug"可在日志里看到 “Connection <...> checked out” 和 “returned to pool” 是否成对出现
自动化检测脚本该监听哪些指标
单看一个数字没意义，得组合判断。一个实用的最小检测集：
- 当前
pool.checked_out()>pool.size * 0.8：高水位预警 - 连续 3 次
SELECT 1失败：判定为集群级故障，非单连接问题 -
pool.overflow()> 0 且持续增长：说明并发突增，但池没扩容（检查max_overflow是否设得太小） - 连接平均获取耗时 > 500ms（可通过
time.time()包裹engine.connect()测量）：可能是网络延迟或数据库负载过高
这些值别硬编码进告警逻辑——通过环境变量或配置中心注入，方便不同环境调整阈值。
最麻烦的其实是长事务占着连接不释放，而监控脚本本身又不敢 kill 连接。这事得靠数据库侧配合查 pg_stat_activity 或 information_schema.PROCESSLIST，光靠 SQLAlchemy 层看不到。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
