1、看執行計划
EXPLAIN, 此命令用於查看SQL的執行計划
總的來說sql的執行計划是一個樹形層次結構， 一般來說閱讀上遵從層級越深越優先， 同一層級由上到下的原則。
來跟着鐵蛋老師讀： 層級越深越優先， 同一層級上到下。
順序知道了，得知道里面的意思了吧， 是的沒錯， 但是這個里面比較具體的一些細節這里就不再展開了，只介紹比較常關注的幾個關鍵字：
重點來了，重點來了，睡覺的玩手機的停一停。王老師要開車了， 啊呸， 開課了。
第一行的括號中從左到右依次代表的是：
（估計）啟動成本，在開始輸出之前花費的時間，例如排序時間。
（估計）總成本， 這里有一個前提是計划節點會完整運行，即所有可用行都會被檢索。實際上一些節點的父節點不會檢索所有可用行（如LIMIT）。
（估計）輸出的總行數，同樣的是基於節點會完整運行的假設。
（估計）輸出行的平均寬度（以字節為單位）
注意：
cost中描述的是啟動成本和總成本，但是到目前為止我們還不知道這個數字代表的具體含義，因為我們不知道它的單位是什么。（所以說這里cost中的成本是具有相對意義，不具有絕對意義）
rows代表的是輸出的總行數，他不是計划節點處理或掃描的行數，而是節點發出的行數。由於使用where子句過濾，這個值通常小於掃描的數目。理想情況下，頂級的rows近似於實際的查詢返回，更新或刪除的行數
2、索引優化
索引盡量建在數據比較分散的列上， 不要在變化很小的字段上加索引，比如性別之類的。
原因就是：
索引本質上是一種空間換時間的操作，通過B Tree這種數據結構減少io的操作次數以此來提升速度。如果在變化很小的字段上建立索引，那么可能單個葉子節點上的數據量也是龐大的，反而增加了io的次數（如果查詢字段有包含非索引列，索引命中之后還需要回表）
3、緩存配置
仔細看了上圖中的執行計划發現有三個個地方有嫌疑，一個是Hash節點， 一個是Sort， 還有一個是Buffers。
在Hash節點中Batches批處理的數量超過了1， 這說明用到了外存， 原來是內存不夠了呀！
Sort節點中，排序方法是歸並， 而且是磁盤排序， 原來也是內存不夠了。
Buffers 節點中，同一個sql執行兩次每次都有新的io，說明緩存空間也不夠，最終這三個現象都指向了內存。
鐵蛋打開pg的配置文件一看， 我靠，窮鬼呀，
共享緩存空間：shared_buffers=512MB,
單獨進程內存：work_mem=4MB,
維護工作內存：maintenance_work_mem=512MB,
才分配了512MB的共享緩存總空間， 進程單獨分配了4M空間用於hash，排序等操作，用於維護的分配了512MB。
設置：
共享緩存區的內存一般分配是內存的1/4，不超過總內存的1/2。 線程內存就看着給了，預計下峰值連接數和均值連接數，做一個權衡，適當提高。
於是鐵蛋將共享緩存區的內存分配為20GB， 單個線程用於hash和排序的分配了200MB。 重啟數據庫， 跑了下執行計划。 sql里面從以前的一分鍾，四五十秒變成了三四秒左右。
原文鏈接：https://blog.csdn.net/MusicIsMyAll/article/details/103465529
其他文章：https://blog.csdn.net/jui121314/article/details/84584848