现场遇到select 语句+where时间字段发现不走时间索引，该表为6KW数据量的一张年表，表中只有时间索引和一个主键索引，该表是新迁移到dm7环境下的，时间列的字段类型是date_time，通过直接执行发现走了全表扫描，通过在表名后面加index 时间索引发现走到了索引扫描。经过询问带佬儿后
分享下个人整理的排查思路：
1.在新接触到的或者新迁移过来的环境下首先排查是否与ini参数或者是否更新索引列的统计信息和是否清除执行计划缓存有关，由于表数据或索引不同，又或一些相关INI参数设置的不同，往往优化器计算出的代价会不相同，因而最后生成的执行计划也不相同，如果数据库无法经常重启可以使用hint先定位到具体原因在进行参数修改
主要需要排查的参数有：
1、ENABLE_INDEX_FILTER:是否进行索引过滤优化，使用索引过滤优化，可以减少中间结果集；该参数建议在现场开启，不会有副作用。
2、OLAP_FLAG:DM数据库能同时支持OLAP和OLTP类型的应用，不过鉴于OLAP与OLTP应用有较大的差异，在DM优化器代价估算时也有不同的处理，因此提供OLAP_FLAG参数供用户指明数据库的应用场景类型，此参数会影响代价计算从而影响最优计划的选择。OLAP_FLAG=0，表示应用类型为OLTP类型应用；OLAP_FLAG=1，表示应用类型为OLAP类型应用；OLAP_FLAG=2，表示应用类型为OLTP类型应用，同时倾向于使用索引范围扫描。也就是说当OLAP_FLAG=2时更倾向于走索引，大部分应用都是OLTP形式的，0和1是全表扫描，该参数在老版本的达梦7中不是2。
在更新统计信息的时候尤其是大表只需要更新索引列的统计信息即可，使用 stat 100 表名（时间列）会缩短更新时间。
该sql没有走最有索引的原因是现场为老版本dm7，OLAP_FLAG的值是0，并且没有更新列上的统计信息导致。另外date_time类型在老板本数据库中需要使用to_date转换才会走到索引更改COMPATIBLE_MODE为0也不好使。