sql语句优化
一、导致查询数据慢的原因
1、数据量大
2、表设计不合理
3、sql语句有待优化
4、没有合理的使用索引
二、优化sql
1、减少*(通配符)使用
2、减少子查询，使用关联查询（left join,right join,inner join,left outer join,right out join）
3、合理的增加冗余的字段（减少表的联接查询）
4、增加中间表进行优化（这个主要是在统计报表的场景，
后台开定时任务将数据先统计好，尽量不要在查询的时候去统计）
5、那些可以过滤掉最大数量记录的条件必须写在WHERE子句的最末尾
三、概念介绍
3.1子查询：嵌套在其他查询中的查询 举一个简单的例子
下面内容引自https://blog.csdn.net/GUI1259802368/article/details/80029623
订单存储在两个表中。每个订单包含订单编号、客户ID、订单日期，在Orders表中存储为一行。各订单的物品存储在相关的OrderItems表中。Orders表不存储顾客信息，只存储顾客ID。顾客的实际信息存储在Customers表中。
现在，假如需要列出订购物品 RGAN01 的所有顾客，应该怎样检索？下面列出具体的步骤。
SELECT cust_name, cust_contact
FROM Customers
WHERE cust_id IN (SELECT cust_id
FROM Order
WHERE order_num IN (SELECT order_num
FROM OrderItems
WHERE prod_id = 'RGAN01'));
可见，在WHERE子句中使用子查询能够编写出功能很强且很灵活的SQL语句。对于能嵌套的子查询的数目没有限制，不过在实际使用时由于性能的限制，不能嵌套太多的子查询。
警告：只能是单列
作为子查询的SELECT语句只能查询单个列。企图检索多个列将返回错误。
警告：子查询和性能
这里给出的代码有效，并且获得了所需的结果。但是，使用子查询并不总是执行这类数据检索的最有效方法。
作为计算字段使用子查询
使用子查询的另一方法是创建计算字段。假如需要显示Customers表中每个顾客的订单总数。订单与相应的顾客ID存储在Orders表中。
执行这个操作，要遵循下面的步骤：
- 从Customers表中检索顾客列表；
- 对于检索出的每个顾客，统计其在Orders表中的订单数目。
正如前两课所述，可以使用SELECT COUNT(*)对表中的行进行计数，并且通过提供一条WHERE子句来过滤某个特定的顾客ID，仅对该顾客的订单进行计数。例如，下面的代码对顾客1000000001的订单进行计数：
输入▼
SELECT cust_name,
cust_state,(SELECT COUNT(*)
FROM Orders
WHERE Orders.cust_id = Customers.cust_id) AS orders
FROM Customers
ORDER BY cust_name;
输出▼
cust_name cust_state orders
------------------------- ---------- ------
Fun4All IN 1
Fun4All AZ 1
Kids Place OH 0
The Toy Store IL 1
Village Toys MI 2
这条SELECT语句对Customers表中每个顾客返回三列：cust_name、cust_state和orders。orders是一个计算字段，它是由圆括号中的子查询建立的。该子查询对检索出的每个顾客执行一次。在此例中，该子查询执行了5次，因为检索出了5个顾客。
子查询中的WHERE子句与前面使用的WHERE子句稍有不同，因为它使用了完全限定列名，而不只是列名（cust_id）。它指定表名和列名（Orders.cust_id和Customers.cust_id）。下面的WHERE子句告诉SQL，比较Orders表中的cust_id和当前正从Customers表中检索的cust_id：
WHERE Orders.cust_id = Customers.cust_id
用一个句点分隔表名和列名，这种语法必须在有可能混淆列名时使用。在这个例子中，有两个cust_id列：一个在Customers中，另一个在Orders中。如果不采用完全限定列名，DBMS会认为要对Orders表中的cust_id自身进行比较。
虽然子查询在构造这种SELECT语句时极有用，但必须注意限制有歧义的列。
3.2关联查询
https://www.cnblogs.com/jianyi12/p/5596274.html
https://www.cnblogs.com/houniaodetiankong/p/9165057.html
这两篇文章说的很清楚了