具体看你的SQL，如果都是用到索引的点查没有问题。

如果都是全表，那么不行。

要看这个表的数据量，如果表特别大，需要建立索引或借助试图来实现，提高查询效率

这题没有说明是什么场景和什么场景比，我假设是比的下面这种情况：
某个oracle数据库中的一张表，对于同一个sql查询，在不考虑缓存的情况下，采集1个用户查询的时间消耗和500个用户同时查询的时间消耗，比较这两种情况下，每个用户的平均耗时，并且通过多次实验，并且考虑极值、平均值、噪音等多种因素，来进行统计分析，定义分析标准，看哪个更慢。
那么结果当然是，500个一起查肯定会比1个查要慢,哪怕是慢1毫秒，也算是慢。
原因：

1. 网络带宽及连接数限制
2. 应用服务器cpu及内存性能限制
3. 数据库服务器cpu及内存性能限制（创建500个连接都要耗不少时间）
4. 数据库磁盘性能限制（比如超大表，没有缓存，需要读文件）

等等一系列原因，但最直白的，在所有条件都一样的情况下，500的开销肯定比1多，至于多多少，那是另一回事了。

实际场景下，应该是已知会变慢，只是看慢了之后的速度是否还可以接受，是否有方法可以改善速度。改善方法多了去了，具体得看场景来进行针对性优化