IM002 错误主因是未安装或未匹配 ODBC 驱动（如缺失 ODBC Driver 17 for SQL Server），需通过 odbcad32.exe 核验驱动存在且位数与 Python 一致；08001 错误则多因 SQL Server 服务未启、TCP/IP 未启用、防火墙拦截或连接字符串错误。
pyodbc 连接 SQL Server 时连不上，常见报错 IM002 或 08001 怎么快速定位
绝大多数连接失败不是代码问题，而是驱动或 DSN 配置缺失。Windows 上必须安装 ODBC Driver 17 for SQL Server（微软官方最新稳定版），不能只靠系统自带的 SQL Server Native Client。确认安装后，在命令行运行 odbcad32.exe 打开 ODBC 数据源管理器，检查“驱动程序”页签里是否存在该驱动名称。
连接字符串建议显式指定驱动，避免依赖系统默认：
conn_str = (
"DRIVER={ODBC Driver 17 for SQL Server};"
"SERVER=your-sql-server;"
"DATABASE=master;"
"UID=sa;"
"PWD=your-pass;"
"TrustServerCertificate=yes;" # 开发环境可临时启用，生产应配证书
)-
TrustServerCertificate=yes是绕过 SSL 证书验证的开关，仅限测试环境；生产必须配有效证书并设为no - 若用 Windows 身份验证，改用
Trusted_Connection=yes，并确保运行脚本的用户有数据库权限 - SQL Server 默认关闭远程 TCP/IP，需在 SQL Server Configuration Manager 中启用“TCP/IP 协议”并重启服务
巡检脚本里怎么安全执行多条健康检查 SQL，又不被阻塞或超时
SQL Server 巡检语句（如查阻塞、查未提交事务、查 tempdb 使用率）容易因锁或资源争用卡住，pyodbc 默认无查询超时，一旦某条 SQL hang 住，整个脚本就停摆。
必须对每个 cursor.execute() 设置 timeout，且按检查项敏感度分级：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
cursor = conn.cursor()
cursor.timeout = 10 # 单位秒，全局设置
cursor.execute("SELECT COUNT(*) FROM sys.dm_exec_requests WHERE blocking_session_id <> 0")- 基础状态类（如
sys.databases状态）设timeout=5 - 动态管理视图类（如
sys.dm_exec_sessions、sys.dm_os_wait_stats）设timeout=10，它们可能触发内部扫描 - 避免在巡检中执行
DBCC CHECKDB这类重量级命令——它不属于“健康检查”，是维护操作，应单独调度 - 每次
execute后立即fetchall()或fetchone()，否则游标占用连接，后续查询可能报HY010错误
如何把 pyodbc 查出的结果结构化成巡检报告，而不是一堆 tuple
pyodbc 默认返回 tuple，字段名得靠 cursor.description 手动映射，写起来啰嗦还容易错位。直接用 cursor.as_dict = True 最省事（pyodbc ≥ 4.0.34 支持）：
cursor = conn.cursor()
cursor.as_dict = True
cursor.execute("SELECT name, state_desc FROM sys.databases")
rows = cursor.fetchall() # 返回 list of dict，如 [{'name': 'master', 'state_desc': 'ONLINE'}]
- 注意：开启
as_dict后无法再用索引取值（如row[0]），只能用键名（如row['name']） - 如果要导出 CSV 或 JSON，直接用
json.dumps(rows)或pandas.DataFrame(rows)，不用手动构造字典 - 对含二进制字段（如
varbinary）的查询，as_dict=True会抛TypeError，此时需先cursor.columns()过滤掉非文本列
巡检结果怎么判断“异常”，而不是只打印原始数值
巡检的价值不在查数据，而在识别风险。比如 tempdb 文件使用率 95% 是危险信号，但单纯 print 出来没人看。应在代码里嵌入业务规则：
tempdb_used_pct = int(rows[0]["used_percent"])
if tempdb_used_pct > 90:
print(f"⚠️ tempdb 使用率 {tempdb_used_pct}%，高于阈值 90%")
# 可触发告警：发邮件、写入日志文件、调企业微信 webhook
elif tempdb_used_pct > 80:
print(f"ℹ️ tempdb 使用率 {tempdb_used_pct}%，接近阈值")
- 阈值不要硬编码，从配置文件（如
config.json）读取，方便不同环境差异化设置 - 对“长时间运行会话”，别只查
total_elapsed_time > 300000（5 分钟），还要排除status = 'sleeping'的闲置连接，否则误报率高 - SQL Server 的
sys.dm_os_performance_counters里很多计数器是累积值（如Batch Requests/sec），需两次采样做差值计算，不能单次读取就下结论
真正的难点从来不是连上数据库，而是理解哪些指标在什么上下文里才算异常——这需要 DBA 经验沉淀到规则里，而不是靠工具自动猜。
