Linux 上优化 Informix 查询性能的系统化方法
一 基线评估与执行计划分析
- 建立可复现的慢 SQL 清单，优先聚焦高成本、高频率、影响面大的语句。
- 使用 SET EXPLAIN ON 生成执行计划，输出到 sqexplain.out，必要时用 onmode -Y <session_id> 针对指定会话抓取；分析是否出现 SEQUENTIAL SCAN、低效 JOIN（如 Nested Loop 在大表上）、估算行数偏差等。
- 结合 onstat、系统工具（如 top/vmstat/sar）观察缓冲命中、I/O 等待、会话阻塞等，定位瓶颈。
- 对可疑计划使用优化器指令进行 A/B 验证，例如：
- {+avoid_index(t idx)} 禁用某索引验证是否更优；
- {+ordered} 强制连接顺序，评估是否改善成本。
- 小示例（验证索引是否真优）：
- 正常执行：set explain on; select count(city) from customer_t where customer_num < 2000000;
- 禁用索引：set explain on; select {+avoid_index(customer_t ‘201_107’)} count(city) from customer_t where customer_num < 2000000;
对比 Estimated Cost、实际耗时与扫描方式（Index Scan vs Sequential Scan）。
二 SQL 与索引优化
- 只查需要的列，避免 **SELECT ***；减少不必要的数据传输与内存占用。
- 优先使用 JOIN 替代复杂子查询，必要时用 临时表 将中间结果物化，降低重复计算与优化复杂度。
- 在 WHERE/JOIN/ORDER BY 涉及的列上建立合适的索引；多列条件使用复合索引，尽量设计覆盖索引以避免回表。
- 避免在索引列上使用函数或计算（如 UPPER(col)、col+1），否则极易导致索引失效与全表扫描。
- 谨慎使用通配符前缀匹配（如 LIKE ‘%abc’），通常无法利用索引；可改为 LIKE ‘abc%’ 或全文/倒排方案。
- 控制结果集规模（如分页、Top-N），减少排序与网络开销。
- 典型优化前后对比（示意）：
- 优化前：SELECT time_records.*, case_name FROM time_records, OUTER cases WHERE … ORDER BY case_no;（耗时约数分钟）
- 优化后：
- SELECT … INTO TEMP foo;
- SELECT * FROM foo ORDER BY case_no;（显著加速）
这类“先物化再排序/关联”的改写，常能有效降低大规模排序与嵌套循环成本。
三 统计信息与执行计划稳定性
- 定期执行 UPDATE STATISTICS，提高行数/基数/直方图质量，帮助优化器选择更优计划。
- 在大批量导入或结构变更后，优先更新统计信息，再评估执行计划是否回归合理。
- 对关键 SQL，保留不同参数下的执行计划与基线指标，便于回滚与对比。
- 必要时使用 SQL Directives（如 {+avoid_index}、{+ordered}）进行受控验证，确认计划改进方向。
四 内存、I O 与并发配置
- 合理提升缓冲池（如 bufpool 等内存参数），减少磁盘 I/O；结合负载逐步调优，避免一次性过度分配。
- 将 数据库文件 与 日志文件 分离到不同物理磁盘或 RAID 卷，降低 I/O 争用；优先使用 SSD。
- 根据 CPU 核数与负载特征配置 虚拟处理器（VP） 与网络参数，提升并行与网络吞吐。
- 适度调整 locksize、logsize 等并发与日志相关参数，减少锁等待与检查点抖动。
- 在 Linux 层面优化文件系统（如 XFS/ext4）、网络栈与 I/O 调度，确保缓存、预读与 TCP 参数匹配数据库工作负载。
五 架构与运维实践
- 对超大型表采用分区表（按时间/地域/业务键），加速范围查询与维护。
- 启用多处理器环境下的并行查询能力，提升扫描与聚合吞吐。
- 应用侧使用连接池，减少频繁建连/断连开销；合并小批量请求，降低往返与解析成本。
- 部署监控与告警（如 onstat/onmode、IBM Data Server Manager、Zabbix），持续跟踪慢查询、锁等待、I/O 与缓冲命中。
- 制定定期维护计划：更新统计信息、重建/重组碎片化索引、清理历史数据，保持执行计划与存储健康。
- 任何变更先在测试环境验证，并保留回滚方案；对关键系统建议灰度与窗口化发布。
