Qlik Viewer通过ODBC连接AWS Postgres查询缓慢问题排查求助

以下是除升级ODBC驱动外的具体排查措施：

• 对比执行计划与会话参数

  • 分别捕获Qlik ODBC和DBeaver JDBC执行查询时的实际执行计划：在Postgres中执行EXPLAIN ANALYZE <你的查询语句>，对比两者的扫描策略、连接类型、行数预估偏差、排序操作。Postgres升级后统计信息可能滞后，不同驱动传递的会话参数也会影响计划选择。
  • 检查两种连接的会话参数差异：在各自的客户端执行SHOW ALL，重点对比work_mem、effective_cache_size、search_path等参数。比如Qlik的ODBC连接可能使用默认的小work_mem，导致哈希连接落盘，大幅降低性能。

• 优化ODBC驱动配置

  • 调整ODBC数据源配置：
    • 开启UseServerSidePrepare参数，让Postgres服务器端预处理语句，减少客户端开销。
    • 调大FetchSize值（如设为10000或更高），减少Qlik与数据库的网络交互次数。
    • 若为只读查询，开启ReadOnly模式，触发驱动的只读优化。
    • 检查类型映射：避免ODBC驱动将字段类型（如日期、字符串）转换成Postgres不兼容的类型，导致索引失效。

• 排查Qlik的查询改写逻辑

  • 开启Qlik的脚本执行日志与ODBC驱动日志，查看实际发送给Postgres的SQL语句，与DBeaver执行的原始语句对比，确认Qlik是否改写了查询（如添加额外过滤、拆分查询）。
  • 检查Qlik的加载策略：是否开启了逐步加载或分批拉取，导致查询被拆分成多次小请求，累加时间变长。若调用存储过程，确认参数类型是否匹配，避免隐式转换导致的性能问题。

• 分析Postgres服务器日志

  • 临时开启Postgres的log_statement = 'all'和log_min_duration_statement = 0，捕获两种连接的查询日志：
    • 对比查询的执行时间、扫描行数、返回行数。
    • 检查是否存在锁等待：Qlik的长连接可能持有锁时间更长，导致阻塞。
    • 查看是否生成大量临时文件（日志中含temp file:），这说明work_mem不足，需调整参数。

• 测试纯ODBC客户端性能

  • 使用纯ODBC工具（如isql命令行、Windows ODBC测试工具）执行相同查询，验证性能：
    • 若纯ODBC也慢，问题出在驱动或Postgres参数配置；若纯ODBC速度接近JDBC，则问题在Qlik的封装逻辑。

• 更新Postgres统计信息

  • Postgres升级后统计信息可能不准确，执行ANALYZE <问题表名>更新统计信息，再测试Qlik查询性能。可通过SELECT * FROM pg_stat_user_tables WHERE relname = '<表名>'查看n_live_tup与实际行数的偏差。

内容的提问来源于stack exchange，提问作者ACaps