SQL优化总结

• 使用explain对sql进行分析：

https://www.cnblogs.com/yycc/p/7338894.html

小表驱动大表的原则：

SELECT * FROM t_emp WHERE dept_id in (SELECT dept_id FROM t_dept) LIMIT 5;
换做exists的写法如下
SELECT * FROM t_emp WHERE EXISTS (SELECT 1 FROM t_dept WHERE t_dept.dept_id = t_emp.dept_id) LIMIT 5;

在实际操作过程中我们要对两张表的dept_id 都设置索引。在一开始我们就讲了一个优化原则即小表驱动大表，在我们使用IN 进行关联查询时，通过上面IN 操作的执行顺序我们是先查询部门表再根据部门表查出来的id信息查询员工信息。我们都知道员工表肯定会有很多的员工信息，但是部门表一般只会有很少的数据信息，我们事先通过查询部门表信息查询员工信息，以小表(t_dept)的查询结果去驱动大表(t_emp)，这种查询方式是效率很高的，也是值得提倡的。
但是我们使用EXISTS 查询时，首先查询员工表，然后根据部门表的查询条件返回的TRUE 或者 FALSE 决定员工表中的信息是否需要保留。这不就是用大的数据表(t_emp) 去驱动小的数据表小的数据表(t_dept)了吗？虽然这种方式也可以查出我们想要的数据，但是这种查询方式是不值得提倡的。

当t_emp 表中数据多于 t_dept 表中的数据时，这时我们使用IN 优于 EXISTS。当t_dept 表中数据多于 t_emp 表中的数据时(我们这里只是假设)，这时我们使用EXISTS 优于 IN。因此是使用IN 还是使用EXISTS 就需要根据我们的需求决定了。但是如果两张表中的数据量差不多时那么是使用IN 还是使用 EXISTS 差别不大。

#################################################
postgresql
PostgreSQL为每个收到的查询设计一个查询规划。选择正确的匹配查询结构和数据属性的规划对执行效率是至关重要要的，所以系统包含一个复杂的规划器来试图选择好的规划。

查询规划是以规划为节点的树形结构

EXPLAIN的输出是每个树节点显示一行，内容是基本节点类型和执行节点的消耗评估。可能会楚翔其他行，从汇总行节点缩进显示节点的其他属性。第一行（最上节点的汇总行）是评估执行计划的总消耗，这个值越小越好。
下面是一个简单的例子：

• 评估开始消耗。这是可以开始输出前的时间，比如排序节点的排序的时间。
• 评估总消耗。假设查询从执行到结束的时间。有时父节点可能停止这个过程，比如LIMIT子句。
• 评估查询节点的输出行数，假设该节点执行结束。
• 评估查询节点的输出行的平均字节数。

EXPLAIN ANALYZE通过EXPLAIN ANALYZE可以检查规划器评估的准确性。使用ANALYZE选项，EXPLAIN实际运行查询，显示真实的返回记录数和运行每个规划节点的时间，例如我们可以得到下面的结果：