1. sql语句查询速度是1分钟慢吗
这样的时间程序是有问题了，你这条sql执行需要一分钟，前台就得等一分钟，没有用户会愿意等，现在查询时间都是毫秒级别的，如果查询时间实在减不下来，可以做缓存，或者索引
2. sql语句联合查询 与 视图想比较的话，那个效率快，为什么。
sql效率比较快，存储过程的好处是不仅快且更安全，但移植性差。视图可以封装查询的复杂性，就像面向对象里类的概念一样。
3. SQL查询速度 Select Count(1)
如果null参与聚集运算，则除count(*)之外其它聚集函数都忽略null。
如：
ID DD
1 e
2 null
select count(*) from table --结果是2
select count(DD) from table ---结果是1
有说count(1)效率高，感觉差不多，没啥区别。
一、关于count的一些谣言：
1、count(*)比count(val)更慢！项目组必须用count(val)，不准用count(*)，谁用扣谁钱！
2、count(*)用不到索引，count(val)才能用到。
3、count(*)是统计出全表的记录，是吞吐量的操作，肯定用不到索引。
4、count(1)比count(*)的速度快。
二、验证count(*)和count(val)
1、首先创建一个表，使用count(*)和count(val)查询比较：
----删除echo表----
SQL> drop table echo purge;
drop table echo purge
*
第 1 行出现错误:
ORA-00942: 表或视图不存在
----创建一张echo的测试表----
SQL> create table echo as select * from dba_objects;
表已创建。
SQL> update echo set object_id = rownum;
已更新72509行。
SQL> commit;
提交完成。
SQL> set timing on
SQL> set linesize 100
SQL> set autotrace on
SQL> select count(*) from echo;
COUNT(*)
----------
72509
已用时间: 00: 00: 00.01
执行计划
----------------------------------------------------------
Plan hash value: 99109176
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 290 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| ECHO | 80064 | 290 (1)| 00:00:04 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
4 recursive calls
0 db block gets
1265 consistent gets
0 physical reads
11060 redo size
425 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select count(*) from echo;
COUNT(*)
----------
72509
已用时间: 00: 00: 00.01
执行计划
----------------------------------------------------------
Plan hash value: 99109176
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 290 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| ECHO | 80064 | 290 (1)| 00:00:04 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
1038 consistent gets
0 physical reads
0 redo size
425 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select count(object_id) from echo;
COUNT(OBJECT_ID)
----------------
72509
已用时间: 00: 00: 00.01
4. sql server 2008查询速度快吗
有没有索引、数据量、同时连接数、查询语句的优化等都会对查询速度有影响的，如果只是简单的查询速度还是很快的
5. SQL的查询速度问题
300条数据对于SQL2000的读操作来说应该是毫秒级就完成的。
你的这个问题，可能出在应用程序、网络质量上。
SQL2000的排查方法：
SQL2000的可能性小，但是为了保险起见，你可以把SQL2000服务器重新启动一次，然后在查询分析器中执行你的SQL语句，看执行时间，若是慢，就要用Ctrl+L来检查是SQL语句中那句话影响了效率，若是还没有找到原因，建议你尽快转移你的SQL2000的数据库，可能是你SQL2000数据库所在的硬盘有坏道了，小心丢失数据！！
DELPHI的排查方法：
看不到你的程序，所以你自己检查好了。
呵呵，希望对你有帮助。
6. sql查询速度
呵呵，这个问题很有趣不是吗？
上面的同志们只是给出一些建议，以我的经验来看（oracle），
如果数据量较大，索引的重复量尽量避免，最好的方式是建立非业务id（最好使用自增或是序列），把这个id建立索引。
你的最大的问题就是，建立了索引后，索引列必须出现在where中，否则索引就白白建立了，比如你的id是从1一直到383000，那么你的语句可以写成
select * from hr_worktime where id>-1
还有就是，where条件中避免出现!=,or,between,等东西，否则索引实效。
如果对您有帮助，请记得采纳为满意答案，谢谢！祝您生活愉快！
vaela
7. SQL连表查询跟一个个表查询那个快各有什么优点和缺点
SQL链接表查询称为联合查询，表查询是单个查询。其区别和优点如下：
1．从发展效率的角度看：
联合查询是需要多个单查询逻辑组合才能完成的查询工作，联合查询只需要一个SQL就可以完成查询工作，即将业务逻辑转化为SQL，由数据库来处理，相对来说，开发效率会更高。
2．从查询效率来看：
单个查询具有更好的可重用性，因此比联合查询更有效。
当读取或写入数据库时，数据库使用锁机制来限制其他连接对其进行操作。由于联邦查询比单个查询慢得多，它们会增加锁争用，因此单个查询更好。
3．从逻辑结构层面来看，分层原则
关联表示业务规则／逻辑。如果经常使用关联查询，就会将大量的业务规则和逻辑放入数据库中执行，这将大大增加CPU、内存、IO等资源的消耗。
4．从资源利用的角度来看
在大多数情况下，并不是所有相关查询的结果都得到了有效的使用。例如，后台管理的列表界面会显示分页、关联查询的结果集，只使用当前页面的数据，而数据库需要消耗额外的资源才能得到整个结果集。
5．从架构的可伸缩性的角度来看
大量的相关查询将导致集中式数据库体系结构难以转化为分布式体系结构，可扩展性优化也难以实现。关联查询方便快捷，开发效率更高。
不使用关系查询在体系结构级别上有很多优势，但是它需要大量的系统分析、设计和开发功能。一般在互联网行业，如用户数量最好重视这方面。
由于数据量小，两个查询的效率基本没有差别，但在实际应用中，需要根据数据量、业务复杂度等进行综合评价。
8. sql:查询时快时慢
如果说是sql server 的话有这种情况，字段越多，查询可能越慢，并且如果你的字段中有比如text，ntext之类的话会有这种情况；
还有，你的这种写法可能也造成执行慢，SQL在执行时有这样一个规则，不知道你是否了解，在执行时，SQL 后台会先执行编译，找到一条最佳查询路径，也就是最快的查询路径，再真正执行查询；这个编译是需要时间的，如果条件复杂，或者由其它的变化而来的条件，会存在编译的查找最佳路径的时间问题；
数据库的字段越多，会有可能越慢，不管是否是空表，至于什么原因，好像MICROSOFT没有说法。
另外1=1这种恒等条件最好也不要加。
9. 一个sql查询5000条很快,查询到20000多条时特别慢
数量太大。sql是用于访问和处理数据库的标准的计算机语言。查询5000条为正常水平，超过10000条系统就会难以成立造成卡顿变慢。
10. sql server数据库中 表的查询速率。
你的两个表中的相同字段都不是统一的数据格式，我很怀疑能不能查询出来就是个问题更不要说查询的速率慢了，首先你应该把其中的一个表中字段强制转换类型，然后再关联
关联后查询速度没有直接查询速率快是很正常，因为它要访问的是两个表关联后的虚拟表，也就是说查询之前它需要把两个表以相同字段b将两个表进行整合成一个虚拟表c保存再内存中，然后进行查询，这样下来速度当然会慢了。