记一次sql查询慢的原因分析（金仓）

在进行数据筛选时，遇到了一个处理4000万条数据的问题（时序数据），在发现这个表很大后，就对其加了索引，然后金仓执行以下sql

SELECT A,B,C，time
FROM Table
WHERE id = #{param.id}
ORDER BY time

 ，但是发现并没有什么用，查询时间需要7秒左右，就很超乎我的想象，但是有时候就会特别快，大概50ms左右。情况很奇怪。但在前后端交互时，稳定7秒左右我最初怀疑是前端接收时数据过大导致不能正常接受处理的问题（正常情况下返回1500多条数据），用swagger测试的时候也只能显示Raw中，不能显示在“相应内容”中，于是在代码执行时加入记录执行时间的代码，

        // 开始时间
        long stime = System.currentTimeMillis();
        // 执行方法
        A.selectAll（）；// 结束时间
        long etime = System.currentTimeMillis();

发现确实是sql执行慢的问题，于是开始优化sql由于该参数是时序参数，就想着只保留到分钟查询的话便会减少很多查询

SELECT 
CONCAT(LEFT(time,16),':00') as time,
A,B,C
FROM Table
WHERE id = #{param.id}
ORDER BY time

但是结果并没有什么变化，依旧需要的查询时间为6秒左右。。。

经过一系列操作之后，最终没有解决，但是忽然发现一个问题，

where id = 1
和
where id = '1'

在mybatis框架中这两种不同的查询都能得到相同的结果，但是其在数据库中的执行方式确实不同的

就是我们的生产环境和本地环境的不同，生产环境的金仓数据库在执行 

where id = 1 时不会走索引，就导致即使我们加了索引，仍然是全表扫描

where id = '1'执行这个会走索引

就是我们的生产环境和本地环境的不同，生产环境的金仓数据库在执行 

但是我在本地测试的时候不会复现这个问题，个人排查了一下，两个数据库并没有什么不同。

于是在查询的代码中进行修改

SELECT A,B,C，time
FROM Table
WHERE id = '${param.id}'
ORDER BY time

然后变能解决本次问题。