1. 盲目增加内存缓冲区（BUFFERS）而不分析命中率
很多管理员认为增大BUFFERS参数（共享内存缓冲区数量）一定能提升性能，但实际上，若当前读命中率已很高（如超过90%），继续增加BUFFERS只会导致内存浪费，甚至增加操作系统页面交换的开销。正确的做法是通过onstat -p命令监控读命中率，只有当命中率持续偏低（如低于80%）时，才逐步增加BUFFERS（建议不超过物理内存的25%-40%），并观察命中率变化。
2. 忽略锁争用的根本原因，仅简单增加LOCKS数量
当onstat -p显示ovlock（锁请求失败次数）或lockwaits（锁等待次数）不为0时，部分管理员会直接大幅增加LOCKS参数（最大锁数量），但这可能掩盖应用层的锁设计问题（如长事务、表级锁滥用）。正确的做法是先用onstat -u和onstat -k找出持有锁的会话和SQL，分析是否存在长时间未提交的事务、不必要的表级锁（应优先使用行级锁），再决定是否增加LOCKS或优化应用逻辑。
3. 不合理的CPU VP（虚拟处理器）配置
NUMCPUVPS（CPU VP数量）的设置需与系统CPU核心数匹配，但常见误区是过度分配（如单核CPU设置多个CPU VP）或不足（如多核CPU仅设置1个CPU VP）。单核CPU建议设置1个CPU VP，多核CPU（如4核以上）设置为“核心数-1”，避免过多CPU VP导致上下文切换开销。此外，需配合AFF_NPROCS（绑定CPU VP到特定核心）参数，将CPU VP绑定到非操作系统核心，减少竞争。
4. 异步I/O（AIO）配置不足导致I/O瓶颈
Informix通过AIO VP实现异步I/O提升磁盘性能，但部分管理员未根据磁盘数量调整NUMAIOVPS（AIO VP数量），导致I/O请求排队。正确的做法是：若磁盘数小于20，每个有数据的磁盘分配1个AIO VP；20-100个磁盘，每2个磁盘分配1个AIO VP；100个以上磁盘，每4个磁盘分配1个AIO VP。通过onstat -R监控LRU脏页队列（dirty pages queued），若队列长度持续大于BUFFERS*LRU_MAX_DIRTY%（默认2%），需增加NUMAIOVPS。
5. 索引优化中的常见错误
WHERE col1=? AND col2=?，索引应为(col1,col2)），否则索引无法生效。UPDATE STATISTICS HIGH，可能导致优化器选择低效的执行计划（如全表扫描而非索引扫描）。6. 并行查询（PDQ）参数设置不合理
DS_MAX_QUERIES（并行查询最大数量）、DS_TOTAL_MEMORY（并行查询总内存）、MAX_PDQPRIORITY（并行查询优先级）等参数设置不当，可能导致并行查询反而降低性能。例如，DS_TOTAL_MEMORY设置过大，会占用过多内存导致系统交换；MAX_PDQPRIORITY设置过高（如100），会使并行查询独占资源，影响其他查询。正确的做法是根据系统内存（如DS_TOTAL_MEMORY设置为256MB-1GB）和并发需求（如DS_MAX_QUERIES设置为10-20）调整，并监控并行查询的资源使用情况。
7. 忽视操作系统内核参数调优
Linux内核参数（如vm.swappiness、fs.file-max、kernel.shmmax）直接影响Informix性能，但部分管理员未针对数据库场景优化。例如，vm.swappiness（交换倾向）默认值（60）过高，会导致系统过早使用swap（影响性能），建议设置为10以下；fs.file-max（最大文件描述符数）需大于Informix的最大连接数（如设置为65536），避免连接数过多导致“Too many open files”错误。
8. 不合理的存储I/O配置
noatime（不更新访问时间）、nodiratime（不更新目录访问时间）可减少磁盘I/O，建议挂载时添加这些选项。
