13518219792
PostgreSQL命令 EXPLAIN ANALYZE 是日常工作中了解和優(yōu)化SQL查詢過程所用到的最強大工具，后接如 SELECT ... ， UPDATE ... 或者 DELETE ... 等SQL語句，命令執(zhí)行后并不返回數據，而是輸出查詢計劃，詳細說明規(guī)劃器通過何種方式來執(zhí)行給定的SQL語句。
十余年的欒川網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網站建設的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整欒川建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯從事“欒川網站設計”,“欒川網站推廣”以來，每個客戶項目都認真落實執(zhí)行。
下面是從 Postgres Using EXPLAIN 提取的查詢：
它生成的查詢計劃：
Postgres構建了一個規(guī)劃節(jié)點的樹結構，以表示所采取的不同操作，其中root根和每個 - 指向其中一個操作。在某些情況下， EXPLAIN ANALYZE 會提供除執(zhí)行時間和行數之外的額外執(zhí)行統(tǒng)計信息，例如上面例子中的 Sort 及 Hash 。除第一個沒有 - 的行之外的任何行都是諸如此類的信息，因此查詢的結構是：
每個樹分支代表子動作，從里到外以確定哪個是“第一個”發(fā)生（盡管同一級別的節(jié)點順序可能不同）。
在 tenk_unique1 索引上執(zhí)行的第一個操作是 Bitmap Index Scan ：
這對應于SQL WHERE t1.unique1 100 。Postgres查找與條件 unique1 100 匹配的行位置。此處不會返回行數據本身。成本估算 (cost=0.00..5.04 rows=101 width=0) 意味著Postgres預期將“花費” 任意計算單位的 5.04 來找到這些行。0.00是此節(jié)點開始工作的成本（在這種情況下，即為查詢的啟動時間）。 rows 是此索引掃描將返回的預估行數， width 是這些返回行的預估大小（以字節(jié)為單位）（0是因為這里只關心位置，而不是行數據的內容）。
因為使用了 ANALYZE 選項運行 EXPLAIN ，所以查詢被實際執(zhí)行并捕獲了計時信息。 (actual time=0.049..0.049 rows=100 loops=1) 表示索引掃描執(zhí)行了1次（ loops 值），結果返回了100行，實際時間是0 ..如果節(jié)點執(zhí)行了多次，實際時間是每次迭代的平均值，可以將該值乘以循環(huán)次數以獲取實際時間。基于成本的最小/最大時間的概念，范圍值也可能會有所不同。通過這些值，我們可以為該查詢生成一個成本比率，每個成本單位為0.049ms / 5.04單位≈0.01ms/單位。
索引掃描的結果將傳遞給 Bitmap Heap Scan 操作。在此節(jié)點中，Postgres將獲取別名為t1的tenk1表中行的位置，根據 unique1 100 條件篩選并獲取行。
當乘以之前計算的0.01值時，我們可以得到成本預期的大概時間（229.20 - 5.07）*0.01≈2.24ms，同時每行實際時間為除以4后的結果：0.526ms。這可能是因為成本估算是取的上限而不是取所有需讀取的行，也或者因為Recheck條件總是生效。
和表順序讀取行（a Seq Scan ）相比， Bitmap Index Scan 和 Bitmap Heap Scan 關聯操作成本要昂貴得多，但是因為在這種情況下只需要訪問相對較少的行，所以關聯操作最終會變得更快。通過在獲取行之前將行按照物理順序排序來進一步加速，這會將單獨獲取的成本降到最低。節(jié)點名稱中的“Bitmap”完成了排序操作。
表掃描的結果（tenk1表中滿足 unique1 100 條件的那些行）將在讀取時被插入到內存的哈希表中。正如我們從成本中看到的那樣，這根本不需要時間。
哈希節(jié)點包括散列桶(hash buckets)和批次數(batches)相關的信息，以及內存使用峰值情況。如果批次 1，則還會包括未顯示的磁盤使用信息。內存占用在100行* 244字節(jié)= 24.4 kB時是有意義的，它非常接近28kB，我們假定這是哈希鍵本身所占用的內存。
接下來，Postgres從別名為t2的tenk2表讀取所有的10000行，并根據tenk1表行的Hash檢查它們。散列連接意味著將一個表的行輸入到內存中的散列（先前的操作中已構建），之后掃描另一個表的行，并根據散列表探測其值以進行匹配。在第二行可以看到“匹配”的條件， Hash Cond: (t2.unique2 = t1.unique2) 。請注意，因為查詢是從tenk1和tenk2中選擇所有值，所以在散列連接期間每行的寬度加倍。
現在已經收集了滿足條件的所有行，可以對結果集進行排序 Sort Key: t1.fivethous 。
Sort節(jié)點包含排序算法 quicksort 相關的信息 ，排序是在內存中還是在磁盤上完成（這將極大地影響速度），以及排序所需的內存/磁盤空間量。
熟悉如何解讀查詢計劃會非常有助于優(yōu)化查詢。例如，Seq Scan節(jié)點通常表示添加索引的必要性，讀取速度可能要快得多。
翻譯并編輯，原文出處：
PostgreSQL 和 MySQL 是將數據組織成表的關系數據庫。這些表可以根據每個表共有的數據鏈接或關聯。關系數據庫使您的企業(yè)能夠更好地了解可用數據之間的關系，并幫助獲得新的見解以做出更好的決策或發(fā)現新的機會。
PostgreSQL 和 MySQL 都依賴于 SQL（結構化查詢語言），這是與管理系統(tǒng)交互的標準語言。SQL 允許使用具有簡單結構的幾行源代碼連接表，大多數非技術員工可以快速學習。
使用 SQL，分析師不需要知道訂單表在磁盤上的位置、如何執(zhí)行查找以查找特定訂單或如何連接訂單表和客戶表。數據庫編譯查詢并計算出正確的數據點。
MySQL 和 PostgreSQL 都支持 JavaScript Object Notation (JSON) 存儲和傳輸數據，盡管 PostgreSQL 也支持 JSONB，這是 JSON 的二進制版本，它消除了鍵的重復和無關的空格。
除了傳統(tǒng)的支持機制外，這兩個數據庫都提供強大的社區(qū)支持。
PostgreSQL，也稱為 Postgres，是一種開源關系數據庫，因其可靠性、靈活性和對開放技術標準的支持而享有盛譽。PostgreSQL 支持非關系和關系數據類型。它被稱為當今可用的最兼容、最穩(wěn)定和最成熟的關系數據庫之一，并且可以輕松處理復雜的查詢。
PostgreSQL 的特性包括：
PostgreSQL 這是一個“一刀切”的解決方案，適用于許多尋求經濟高效的方法來改進其數據庫管理系統(tǒng) (DBMS) 的企業(yè)。它具有足夠的可擴展性和多功能性，可以通過強大的擴展生態(tài)系統(tǒng)快速支持各種專業(yè)用例，涵蓋時間序列數據類型和地理空間分析等工作。作為開源數據庫解決方案構建的 PostgreSQL 完全不受許可限制、供應商鎖定的可能性或過度部署的風險。PostgreSQL 通過對象關系數據庫管理系統(tǒng) (ORDBMS) 進行管理。
PostgreSQL 負責管理業(yè)務活動的在線事務處理 (OLTP)協議的企業(yè)數據庫管理員提供了理想的解決方案，包括電子商務、客戶關系管理系統(tǒng) (CRM) 和財務分類帳。它也是管理接收、創(chuàng)建和生成的數據分析的理想選擇。
這些是 PostgreSQL 的一些主要優(yōu)點：
MySQL — 一種快速、可靠、可擴展且易于使用的開源關系數據庫系統(tǒng) — 旨在處理關鍵任務、高負載的生產應用程序。它是一種常見且易于啟動的數據庫，內存、磁盤和 CPU 利用率較低，有關系數據庫管理系統(tǒng) (RDMS) 管理。MySQL Community Edition 是一個由活躍的在線社區(qū)支持的免費下載版本。
MySQL 功能包括所有 SQL 標準命令以及事務和 ACID 合規(guī)性（代表原子性、一致性、隔離性和持久性）。
兩個最常見的關系數據庫是什么 MySQL 和 Oracle。MySQL 不是 SQL Server 的同義詞，SQL Server 是 Microsoft 許可產品，與 MAC OS X 缺乏兼容性。
MariaDB 經常與 MySQL 混淆，它是 MySQL 的一個開源分支，速度更快，提供更多存儲引擎 (12)，但功能有限。MySQL 和 MariaDB 使用的存儲引擎都是 InnoDB。InnoDB 提供標準的 ACID 兼容特性。與 MySQL 不同，MariaDB 不支持數據屏蔽或動態(tài)列表。
MySQL 通常用作 Web 數據庫來存儲各種信息類型，從單個信息數據點到為組織提供的產品或服務的完整列表。它是LAMP（Linux 操作系統(tǒng)、Apache HTTP 服務器、MySQL RDBMS 和 PHP 編程語言）的基礎組件，這是一種有助于創(chuàng)建API、Web 應用程序和網站的軟件堆棧模型。
MySQL Workbench 是一個單一的、集成的可視化 SQL 平臺，用于 MySQL 數據庫的創(chuàng)建、開發(fā)、設計和管理。
MySQL 為市場提供了許多好處，包括：
PostgreSQL 和 MySQL 之間有很多不同之處。特性、功能和優(yōu)勢方面的一些差異如下：
總之，PostgreSQL 和 MySQL 都有不同的用途，它們之間的選擇取決于企業(yè)目標和資源。一般來說，PostgreSQL 是一個更強大、更高級的數據庫管理系統(tǒng)，非常適合需要在大型環(huán)境中快速執(zhí)行復雜查詢的組織。但是，對于預算和空間更受限制的公司來說，MySQL 是一個理想的解決方案。
目 錄
總 結
PostgreSQL 通過調用系統(tǒng) fsync() 或者其他使得事務內容寫入到物理磁盤，這樣可以保證操作系統(tǒng)或者數據庫出現宕機后，仍然可以恢復到某一個一致性的狀態(tài)。理論上講 PostgreSQL 的 fsync 功能關閉，可以實現性能的提升，但是帶來的影響就是需要承擔數據的丟失，因為出現系統(tǒng)宕機或者數據庫崩潰的時候有一些數據是沒有落盤的。
本文將驗證 fsync 參數的性能影響，以及參數關閉時數據庫宕機后的影響。
數據量：1000W
fsync 參數：on
初始化表：user_info
pgbench 壓測
pgbench 結果
pgbench 壓測
pgbench 結果
數據量：1000W
fsync 參數：off
初始化表：user_info
pgbench 壓測
pgbench 結果
pgbench 壓測
pgbench 結果
通過對比發(fā)現，將 fsync 改為 off，對于讀 TPS，參數 fsync 的影響不大，對于寫 TPS，性能有一定提升。
現在驗證參數關閉時數據庫宕機后的影響
首先，使用將數據庫性能跑起來
然后，模擬服務器斷電
之后，啟動數據庫
提示信息：比致命錯誤還過分的錯誤。
結果：數據庫無法啟動，原因就是因為無法找到一個有效的 checkpoint 記錄，這就是因為 fsync 設置為 off，由于數據庫異常宕機導致。可以通過使用 pg_resetxlog 恢復數據庫，但是會造成部分數據無法找回，數據丟失；也可以通過備份恢復，同樣也會丟失部分數據。
fsync 參數對于讀 TPS 的性能影響不大，對于寫 TPS 的性能有一些影響，設置為 off，寫 TPS 性能有一定提升，但是存在數據庫宕機后無法正常啟動，即使恢復后啟動數據庫，也會有數據丟失的很大風險。因此生產環(huán)境非必要時，不要將此參數設置為 off，還是使用默認的 on 比較穩(wěn)妥。
