查 单表两千条数据，代码中sql执行与返回6秒, 将表数据清空，毫秒返回， 插入400条数据， 耗时一秒多. sql在程序中很慢， 在数据库执行则很快。
sql:
select name, accnt_id, ban_accnt, ban_name, system_no, curren_id, party_id, product_id from ext_accnt;
整个表十几个字段， 表数据量1980.
使用如下别名则很快。
select '1' name, '1' accnt_id, '1' ban_accnt, '1' ban_name, '1' system_no, '1' curren_id, '1' party_id, '1' product_id from ext_accnt;
主要原因应该还是网络原因，检查一下数据库连接配置，连接池配置这些，也有可能是oracle11G的配置问题
是不是没有加索引
单表两千条数据肯定不涉及索引之类的问题，即便是查全表数据也用不了两三秒，最可能的原因就是网络原因，或者是连接池的配置问题
这你就得排查了，既然数据直接执行查询很快，但是程序查询慢，就说明是程序的问题，程序里面其实就有这几个阶段，排查一下呗；
首先就是数据库连接问题，但是你说查询其他表快，这个可以排除了；
然后是sql问题，你数据库执行快，这个也排除了；
再有就是封装问题了，不要用对象接受，直接用map接受返回值，你可以测试一下看看？
select '1' name, '1' accnt_id, '1' ban_accnt, '1' ban_name, '1' system_no, '1' curren_id, '1' party_id, '1' product_id from ext_accnt;
你这里搜索的都是1的值，搜索出来的结果不一样吧。select 1是查询库有多少条数据
表名，字段名全都换大写
估计你service层有问题 你查查呗
兄弟，要不是认真看前几楼的回复，我还以为你是来捣乱的。2000条，全表扫描也不用几百毫秒的！！！为什么上面还有回答讨论几秒几秒的？？？如果2000条数据，你写的代码无论有没有加索引，就这么简单的sql，除掉网络问题，你都能搞出几百ms，直接往死里打。
再说一点：你使用别名的那条sql，你那是直接查常量值啊，没有任何参考帮助排除问题的意义
几个排查思路建议：
首先看下我的理解是不是你的情况：本地跑，数据库在本地，跑起来没有问题。生产上一跑，发现6s。把sql提出来直接在生产上数据库跑，很快一点问题没有。那么那么，耗时6s就不是SQL执行耗时对吧！6s是哪条链路这个可以在详细点，我猜测就是从接口请求到接口收到响应对吧？那推荐排查：首先SQL没问题的哈，这么简单的SQL有个鬼问题
（1）网络情况-服务端和数据库的网络：这个很好排查，就是看是不是大多数SQL都时快时慢，如果是那就网络不稳定！
（2）检查代码逻辑，，，说实话，不管代码怎么搞，都不可能给你卡出6s，大概率是有外部访问导致的，比如redis、消息队列或者多线程之类的
（3）如果是客户端（浏览器、app）感知的6s，那你不得查查客户端和服务器之间的网络吗，主要是这6s是哪些范围，一个一个去排查，大可能是网络、外部访问导致的
1、写一个接口，什么都不干，单查这张表，看一下查询时间，如果时间快，那么就是程序代码和网络的问题
2、请生产库管理人员将sql语句直接在生成库运行，查看速率，如果也慢，那就是数据库问题
几个方向入手定位问题：
1、生产环境和测试环境的硬件配置
2、测试环境表结构和生产环境表结构是否一致
3、生产环境的执行情况是否存在阻塞死锁等情况 show processlist可以查看整个库运行中的sql情况
4、测试环境和生产环境的jvm配置情况
目测问题出现在2、3中，楼主可以先定位排查一下
有没有可能是oracle高水位HWM的问题，如果确定表数据不再使用，可以使用truncate 截断表，然后重试下，如果尝试插入后正常，极有可能是高水位的问题（也可以提前看下sql执行计划，scan的数据块数，或者查询该表的统计信息目前的数据块数量，如果表中无数据但是数据块大小为几千或上万，说明存在高水位问题）
truncate table 表名
需要用服务器接口进行查询，自己本地测试由于是远程传输的问题，所以比较慢
要不先看看sql的运行情况？
你的网是不是不大好？