Linux 上 Informix 索引使用注意事项
一 设计与创建
- 为高频出现在 WHERE、JOIN、ORDER BY 中的列建立索引；多列经常共同出现时优先使用复合索引，并将选择性高（唯一值多）的列放在左侧；长字符串优先考虑前缀索引以节省空间。避免创建重复或冗余索引，以降低写入开销与存储占用。对大文本或 JSON 等类型，优先考虑函数索引或表达式索引来匹配实际查询形态。必要时使用覆盖索引减少回表。对范围/排序字段合理组织复合索引顺序，以同时服务于过滤与排序。对空间数据，可使用 Spatial DataBlade 提供的 R-Tree 索引（如通过 loadshp 导入 Shapefile 后在空间列上构建空间索引）。
二 使用与查询编写
- 避免在索引列上使用函数或表达式（如 UPPER(col)、col + 1），否则通常会导致索引失效与全表扫描；LIKE 查询尽量避免以通配符 % 开头。需要大小写不敏感匹配时，优先使用函数索引（如 CREATE INDEX … ON t(UPPER(col))）或映射为 NCHAR/UTF-8 并配合合适的排序规则。尽量使用覆盖索引或只选择必要列，减少回表与 I/O。通过 EXPLAIN 检查执行计划，确认是否走索引、是否发生全表扫描或低效排序；必要时使用查询提示（如 INDEX 提示）引导优化器选择目标索引。合理控制返回行数（分页、LIMIT/SKIP FIRST），降低排序与网络开销。
三 维护与统计
- 定期更新统计信息，让优化器获得准确的行数、密度与直方图，从而生成更优执行计划；在大量 INSERT/UPDATE/DELETE 后尤需执行。对高变更表或索引碎片明显上升的场景，按需执行重建索引以恢复 B-Tree 层高与页面利用率。建立例行巡检：使用 onstat、oncheck 等工具观察索引使用、锁等待、缓冲命中与 I/O 情况，结合慢 SQL 回溯定位缺失或低效索引。对关键业务表，建议建立索引使用基线与变更评审，避免随意新增/删除索引引发回归。
四 高可用与复制场景
- 在启用了 RSS 的 HDR 环境中，创建索引时会将索引页面写入逻辑日志并复制到从节点，保证从节点在索引构建期间与之后均可直接使用，无需额外在线窗口。可通过 ONCONFIG 参数 LOG_INDEX_BUILDS=1 启用（或 onmode -wf LOG_INDEX_BUILDS 1 动态设置）；一旦存在 RSS 节点，切勿关闭该参数，否则可能影响复制一致性与可用性。
五 监控与故障排查
- 使用 tbstat 观察会话与锁等待，关注 LOCKS、DEADLOCKS、DLTOUTS 等指标；若 DEADLOCKS 上升，可适当调整 DEADLOCK_TIMEOUT（默认 60 秒）并优化事务粒度与索引命中率。通过 tbstat -u/-g 与 onstat 检查是否存在锁溢出（OVLOCK）、**缓冲区不足（OVBUF）**等资源瓶颈，必要时调整相关配置并补充/重建索引以减少扫描与锁竞争。