如何看查询计划?
若一个查询表现出很差的性能，查看查询计划可能有助于找到问题点。下面是 一些需要查看的东西：
计划中是否有一个操作花费时间超长？
查询计划中是否有一个操作花费 了大部分的处理时间？例如，如果一个索引扫描比预期的时间超长，也许 该索引已经处于过期状态，需要考虑重建索引。还可临时尝试使用enable_ 之类的参数查看是否可以强制选择不同的计划(可能会更好的效果)，这些 参数可以设置特定的查询计划操作为开启或关闭状态。
规划器的评估是否接近实际情况？
执行EXPLAIN ANALYZE查看规划器 评估的记录数与真实运行查询操作返回的记录数是否一致。如果差异巨大， 可能需要在TABLE相关的COLUMN上收集更多的统计信息。
选择性强的条件是否较早出现？
选择性强的条件应该被较早应用，从而使 得在计划树中上传的记录更少。如果查询计划在选择性评估方面没有对查 询条件作出正确的判断，可能需要在TABLE相关的COLUMN上收集更多 的统计信息。相关信息可查看”维护数据库统计信息”章节。也可以尝试调 整SQL语句WHERE子句的顺序。
规划器是否选择了最佳的关联顺序？
如查询使用多表关联，需要确保规划 器选择了选择性最好的关联顺序。那些可以消除大量记录的关联应在更早 的被执行，从而使得在计划树中上传的记录更少。如果规划器没有选择最 佳的关联顺序，可以尝试设置join_collapse_limit=1并在SQL语句中构造特 定的关联顺序，从而可以强制规划器选择指定的关联顺序。还可以尝试在 TABLE相关的COLUMN上收集更多的统计信息。相关信息可查看”维护数
规划器是否选择性的扫描分区表？
如果使用了分区，规划器是否值扫描了 查询条件匹配的相关子表？父表的扫描返回0条记录(本该如此，因为父表 不包含任何数据)。作为显示选择性扫描分区查询计划的例子。
规划器是否合适的选择了HASH聚合与HASH关联操作？
HASH操作通常 比其他类型的关联和聚合要快。记录在内存中的比较排序比磁盘快。要使 用HASH操作，必须有足够的工作内存用以放置评估的记录。对于特定才 查询可以尝试增加工作内存来查看是否能够获得更好的性能。如果可能， 为该查询执行EXPLAIN ANALYZE，将可以得到哪些操作缓存到磁盘(由 于工作内存不足导致)，多少的工作内存被使用，以及需要多少内存以保证 不缓存到磁盘。例如：
Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).
Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen
workfile I/O affecting 2 workers.
需要注意的是wanted信息只是一个提示，基于写出工作文件的量是不精确的。 需要的最小work_mem可能会比提示的值或多或少一些。