如何解决SQL查询速度太慢?

呵呵，这个问题很有趣不是吗？
上面的同志们只是给出一些建议，以我的经验来看（oracle），
如果数据量较大，索引的重复量尽量避免，最好的方式是建立非业务id（最好使用自增或是序列），把这个id建立索引。
你的最大的问题就是，建立了索引后，索引列必须出现在where中，否则索引就白白建立了，比如你的id是从1一直到383000，那么你的语句可以写成
select

from
hr_worktime
where
id>-1
还有就是，where条件中避免出现!=,or,between,等东西，否则索引实效。

1、如果mysql的data数据很少，内存足够大，可以把data防止到内存盘中。
linux如下设置内存盘：
mount -t ramfs none /ram
默认使用内存一半
如果内存不够大，系统有多个硬盘，则把mysql应用程序和data目录分开到不同硬盘上。
2、mysql的表设置为myiasm，比同等条件下的innodb能快20倍以上
3、导入完成以后才创建数据库索引
4、导入完成以后根据需要转换为其他engine，比如innodb
5、多条数据插入一个表，可以使用多记录方式：
insert into tablename values(’xxx’,'xxx’),(’yyy’,'yyy’)…;
6、如果多个mysql执行导入，可以使用delayed
insert delayed into tablename values(’sss’,’ssss’);
7、大文件sql文件可以用split分成多份再导
8、同等条件下，redhat比ubuntu强很多（几乎肯定）

如何提高SQL语言的查询效率
由于SQL是面向结果而不是面向过程的查询语言，所以一般支持SQL语言的大型关系型数据库都使用一个基于查询成本的优化器，为即时查询提供一个最佳的执行策略。对于优化器，输入是一条查询语句，输出是一个执行策略。
一条SQL查询语句可以有多种执行策略，优化器将估计出全部执行方法中所需时间最少的所谓成本最低的那一种方法。所有优化都是基于用记所使用的查询语句中的where子句，优化器对where子句中的优化主要用搜索参数(Serach Argument)。
搜索参数的核心思想就是数据库使用表中字段的索引来查询数据，而不必直接查询记录中的数据。
带有 =、<、<=、>、>= 等 *** 作符的条件语句可以直接使用索引，如下列是搜索参数：
emp_id = "10001" 或 salary > 3000 或 a =1 and c = 7
而下列则不是搜索参数：
salary = emp_salary 或 dep_id != 10 或 salary 12 >= 3000 或 a=1 or c=7
应当尽可能提供一些冗余的搜索参数，使优化器有更多的选择余地。请看以下3种方法：
第一种方法：
select employeeemp_name,departmentdep_name from department,employee where (employeedep_id = departmentdep_id) and (departmentdep_code='01') and (employeedep_code='01');
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals '01'
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第二种方法：
select employeeemp_name,departmentdep_name from department,employee where (employeedep_id = departmentdep_id) and (departmentdep_code='01');
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals '01'
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第一种方法与第二种运行效率相同，但第一种方法最好，因为它为优化器提供了更多的选择机会。
第三种方法：
select employeeemp_name,departmentdep_name from department,employee where (employeedep_id = departmentdep_id) and (employeedep_code='01');
这种方法最不好，因为它无法使用索引，也就是无法优化……
使用SQL语句时应注意以下几点：
1、避免使用不兼容的数据类型。例如，Float和Integer，Char和Varchar，Binary和Long Binary不兼容的。数据类型的不兼容可能使优化器无法执行一些本可以进行的优化 *** 作。例如：
select emp_name form employee where salary > 3000;
在此语句中若salary是Float类型的，则优化器很难对其进行优化，因为3000是个整数，我们应在编程时使用30000而不要等运行时让DBMS进行转化。
2、尽量不要使用表达式，因它在编绎时是无法得到的，所以SQL只能使用其平均密度来估计将要命中的记录数。
3、避免对搜索参数使用其他的数学 *** 作符。如：
select emp_name from employee where salary 12 > 3000;
应改为：
select emp_name from employee where salary > 250;
4、避免使用 != 或 <> 等这样的 *** 作符，因为它会使系统无法使用索引，而只能直接搜索表中的数据。

索引对数据库检索优化时很重要的一个概念聚集索引在SQL中是唯一的也就是说聚集索引时一个很宝贵的资源但是SQL SERVER在自动分配索引的时候默认总是将ID主键分配为聚集索引其实是很浪费的通常情况下你可以通过语句创建聚集索引到你使用率最高的条件字段上面去，当然你必须先分配聚集索引然后再去分配主键，否则主键创建时就会自动占用聚集索引然后非聚集索引不能设置过滥，设置过滥会导致目录增多最后反而导致查询缓慢优化不是纯粹理论上的东西，理论教会你怎么去使用尝试才能获取经验

这个要具体诊断， *** 作系统版本，sql2008R2版本，硬盘、网络都有关系，
提升最简单的办法是提升硬件配置， *** 作系统是win2008 R2 64位，sql 2008R2也是64位的，加内存是最简单便捷的，另外还有换ssd，或者使用san存储来存放数据库文件。
你都来这里问了，证明你们没什么专业技术力量，最好联系你们ERP的供应商处理吧。

1、使用ordered提示

Oracle必须花费大量的时间来剖析多表的合并，用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并，那么有时就会需要超过30分钟的时间来剖析，Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。

2、使用ordered_predicates

ordered_predicates提示在查询的WHERE子句里指定的，并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下，Oracle会使用下面这些步骤来评估SQL判断的顺序：子查询的评估先于外层WHERE子句里的Boolean条件。

所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估，即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。

3、限制表格合并评估的数量

提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数，这个参数控制着在评估一个查询的时候，基于消耗的优化器所评估的可能合并数量。

扩展资料：

1、表设计的优化，数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。

2、语句的查询优化，保证在实现功能的基础上，尽量减少对数据库的访问次数；

3、建立高效的索引创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。

大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。

4、强制查询转换，有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取。

在已有的 MySQL 服务器之上使用 Apache Spark （无需将数据导出到 Spark 或者 Hadoop 平台上），这样至少可以提升 10 倍的查询性能。使用多个 MySQL 服务器（复制或者 Percona XtraDB Cluster）可以让我们在某些查询上得到额外的性能提升。你也可以使用 Spark 的缓存功能来缓存整个 MySQL 查询结果表。
思路很简单：Spark 可以通过 JDBC 读取 MySQL 上的数据，也可以执行 SQL 查询，因此我们可以直接连接到 MySQL 并执行查询。那么为什么速度会快呢？对一些需要运行很长时间的查询（如报表或者BI），由于 Spark 是一个大规模并行系统，因此查询会非常的快。MySQL 只能为每一个查询分配一个 CPU 核来处理，而 Spark 可以使用所有集群节点的所有核。在下面的例子中，我们会在 Spark 中执行 MySQL 查询，这个查询速度比直接在 MySQL 上执行速度要快 5 到 10 倍。
另外，Spark 可以增加“集群”级别的并行机制，在使用 MySQL 复制或者 Percona XtraDB Cluster 的情况下，Spark 可以把查询变成一组更小的查询（有点像使用了分区表时可以在每个分区都执行一个查询），然后在多个 Percona XtraDB Cluster 节点的多个从服务器上并行的执行这些小查询。最后它会使用map/reduce 方式将每个节点返回的结果聚合在一起形成完整的结果。

---