主頁 > 資料庫 > 【干貨總結】:可能是史上最全的MySQL和PGSQL對比材料

【干貨總結】:可能是史上最全的MySQL和PGSQL對比材料

2020-09-10 15:02:18 資料庫

【干貨總結】:可能是史上最全的MySQL和PGSQL的對比材料

運維了MySQL和PGSQL已經有一段時間了，最近接到一個資料庫選型需求，于是便開始收集資料整理了一下，然后就有了下面的對比表

關鍵詞：PostgreSQL 11、MySQL5.7

 

比較版本：PostgreSQL 11    VS      MySQL5.7（innodb引擎） Oracle官方社區版 著作權情況：PostgreSQL 11（免費開源）、MySQL5.7 Oracle官方社區版（免費開源）
1. CPU限制 PGSQL 沒有CPU核心數限制，有多少CPU核就用多少     MySQL 能用128核CPU，超過128核用不上

 2. 組態檔引數

PGSQL 一共有255個引數，用到的大概是80個，引數比較穩定，用上個大版本組態檔也可以啟動當前大版本資料庫     MySQL 一共有707個引數，用到的大概是180個，引數不斷增加，就算小版本也會增加引數，大版本之間會有部分引數不兼容情況
3. 第三方工具依賴情況 PGSQL 只有高可用集群需要依靠第三方中間件，例如：patroni+etcd、repmgr     MySQL 大部分操作都要依靠percona公司的第三方工具（percona-toolkit，XtraBackup），工具命令太多，學習成本高，高可用集群也需要第三方中間件，官方MGR集群還沒成熟

4. 高可用主從復制底層原理

PGSQL 物理流復制，屬于物理復制，跟SQL Server鏡像/AlwaysOn一樣，嚴格一致，沒有任何可能導致不一致，性能和可靠性上，物理復制完勝邏輯復制，維護簡單        MySQL 主從復制，屬于邏輯復制，（sql_log_bin、binlog_format等引數設定不正確都會導致主從不一致）
大事務并行復制效率低，對于重要業務，需要依賴 percona-toolkit的pt-table-checksum和pt-table-sync工具定期比較和修復主從一致
主從復制出錯嚴重時候需要重搭主從
MySQL的邏輯復制并不阻止兩個不一致的資料庫建立復制關系

5. 從庫只讀狀態

PGSQL 系統自動設定從庫默認只讀，不需要人工介入，維護簡單        MySQL 從庫需要手動設定引數super_read_only=on，讓從庫設定為只讀，super_read_only引數有bug，鏈接：https://baijiahao.baidu.com/s?id=1636644783594388753&wfr=spider&for=pc

6. 版本分支

PGSQL 只有社區版，沒有其他任何分支版本，PGSQL官方統一開發，統一維護，社區版有所有功能，不像SQL Server和MySQL有標準版、企業版、經典版、社區版、開發版、web版之分
國內外還有一些基于PGSQL做二次開發的資料庫廠商，例如：Enterprise DB、瀚高資料庫等等，當然這些只是二次開發并不算獨立分支     MySQL 由于歷史原因，分裂為三個分支版本，MariaDB分支、Percona分支 、Oracle官方分支，發展到目前為止各個分支基本互相不兼容
Oracle官方分支還有版本之分，分為標準版、企業版、經典版、社區版

7. SQL特性支持

PGSQL SQL特性支持情況支持94種，SQL語法支持最完善，例如：支持公用表運算式（WITH查詢）     MySQL SQL特性支持情況支持36種，SQL語法支持比較弱，例如：不支持公用表運算式（WITH查詢）   關于SQL特性支持情況的對比，可以參考：http://www.sql-workbench.net/dbms_comparison.html

8. 主從復制安全性

PGSQL
同步流復制、強同步（remote apply)、高安全，不會丟資料
PGSQL同步流復制：所有從庫宕機，主庫會罷工，主庫無法自動切換為異步流復制（異步模式），需要通過增加從庫數量來解決，一般生產環境至少有兩個從庫
手動解決：在PG主庫修改引數synchronous_standby_names =''，并執行命令： pgctl reload ，把主庫切換為異步模式 主從資料完全一致是高可用切換的第一前提，所以PGSQL選擇主庫罷工也是可以理解     MySQL
增強半同步復制 ，mysql5.7版本增強半同步才能保證主從復制時候不丟資料
mysql5.7半同步復制相關引數：
引數rpl_semi_sync_master_wait_for_slave_count 等待至少多少個從庫接收到binlog，主庫才提交事務，一般設定為1，性能最高
引數rpl_semi_sync_master_timeout 等待多少毫秒，從庫無回應自動切換為異步模式，一般設定為無限大，不讓主庫自動切換為異步模式
所有從庫宕機，主庫會罷工，因為無法收到任何從庫的應答包 手動解決：在MySQL主庫修改引數rpl_semi_sync_master_wait_for_slave_count=0

9. 多欄位統計資訊

PGSQL 支持多欄位統計資訊     MySQL 不支持多欄位統計資訊

10. 索引型別

PGSQL 多種索引型別（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，運算式索引）     MySQL btree 索引，全文索引（低效），運算式索引(需要建虛擬列)，hash 索引只在記憶體表

11. 物理表連接演算法

PGSQL 支持  nested-loop join 、hash join 、merge join        MySQL 只支持  nested-loop join

12. 子查詢和視圖性能

PGSQL 子查詢，視圖優化，性能比較高     MySQL 視圖謂詞條件下推限制多，子查詢上拉限制多

13. 執行計劃即時編譯

PGSQL 支持  JIT    執行計劃即時編譯，使用LLVM編譯器     MySQL 不支持執行計劃即時編譯

14. 并行查詢

PGSQL 并行查詢（多種并行查詢優化方法），并行查詢一般多見于商業資料庫，是重量級功能     MySQL

有限，只支持主鍵并行查詢

15. 物化視圖

PGSQL 支持物化視圖     MySQL

不支持物化視圖

16. 插件功能

PGSQL 支持插件功能，可以豐富PGSQL的功能，GIS地理插件，時序資料庫插件， 向量化執行插件等等     MySQL

不支持插件功能

17. check約束

PGSQL 支持check約束     MySQL

不支持check約束，可以寫check約束，但存盤引擎會忽略它的作用，因此check約束并不起作用（mariadb 支持）

18. gpu 加速SQL

PGSQL 可以使用gpu 加速SQL的執行速度        MySQL

不支持gpu 加速SQL 的執行速度   

19. 資料型別

PGSQL 資料型別豐富，如 ltree，hstore，陣列型別，ip型別，text型別，有了text型別不再需要varchar，text型別欄位最大存盤1GB     MySQL

資料型別不夠豐富

20. 跨庫查詢

PGSQL 不支持跨庫查詢，這個跟Oracle 12C以前一樣     MySQL

可以跨庫查詢

21. 備份還原

PGSQL 備份還原非常簡單，時點還原操作比SQL Server還要簡單，完整備份+wal歸檔備份（增量）
假如有一個三節點的PGSQL主從集群，可以隨便在其中一個節點做完整備份和wal歸檔備份

    MySQL

備份還原相對不太簡單，完整備份+binlog備份（增量）
完整備份需要percona的XtraBackup工具做物理備份，MySQL本身不支持物理備份
時點還原操作步驟繁瑣復雜

22. 性能視圖

PGSQL 需要安裝pg_stat_statements插件，pg_stat_statements插件提供了豐富的性能視圖：如：等待事件，系統統計資訊等
不好的地方是，安裝插件需要重啟資料庫，并且需要收集性能資訊的資料庫需要執行一個命令：create extension pg_stat_statements命令
否則不會收集任何性能資訊，比較麻煩

  MySQL

自帶PS庫，默認很多功能沒有打開，而且打開PS庫的性能視圖功能對性能有影響（如：記憶體占用導致OOM bug）

23. 安裝方式

PGSQL 有各個平臺的包rpm包，deb包等等，相比MySQL缺少了二進制包，一般用原始碼編譯安裝，安裝時間會長一些，執行命令多一些

  MySQL

有各個平臺的包rpm包，deb包等等，原始碼編譯安裝、二進制包安裝，一般用二進制包安裝，方便快捷

24. DDL操作

PGSQL 加欄位、可變長欄位型別長度改大不會鎖表，所有的DDL操作都不需要借助第三方工具，并且跟商業資料庫一樣，DDL操作可以回滾，保證事務一致性

  MySQL 由于大部分DDL操作都會鎖表，例如加欄位、可變長欄位型別長度改大，所以需要借助percona-toolkit里面的pt-online-schema-change工具去完成操作
將影響減少到最低，特別是對大表進行DDL操作
DDL操作不能回滾

25. 大版本發布速度

PGSQL PGSQL每年一個大版本發布，大版本發布的第二年就可以上生產環境，版本迭代速度很快 PGSQL 9.6正式版推出時間：2016年 PGSQL 10 正式版推出時間：2017年
PGSQL 11 正式版推出時間：2018年
PGSQL 12 正式版推出時間：2019年  

MySQL
MySQL的大版本發布一般是2年~3年，一般大版本發布后的第二年才可以上生產環境，避免有坑，版本發布速度比較慢
MySQL5.5正式版推出時間：2010年
MySQL5.6正式版推出時間：2013年
MySQL5.7正式版推出時間：2015年
MySQL8.0正式版推出時間：2018年

26. returning語法

PGSQL 支持returning語法，returning clause 支持 DML 回傳 Resultset，減少一次 Client <-> DB Server 互動

  MySQL 不支持returning語法

27. 內部架構

PGSQL 多行程架構，并發連接數不能太多，跟Oracle一樣，既然跟Oracle一樣，那么很多優化方法也是相通的，例如：開啟大頁記憶體

  MySQL

多執行緒架構，雖然多執行緒架構，但是官方有限制連接數，原因是系統的并發度是有限的，執行緒數太多，反而系統的處理能力下降，隨著連接數上升，反而性能下降
一般同時只能處理200 ~300個資料庫連接

28. 聚集索引

PGSQL 不支持聚集索引，PGSQL本身的MVCC的實作機制所導致

  MySQL

支持聚集索引

29. 空閑事務終結功能

PGSQL 通過設定 idle_in_transaction_session_timeout 引數來終止空閑事務，比如：應用代碼中忘記關閉已開啟的事務，PGSQL會自動查殺這種型別的會話事務

  MySQL

不支持終止空閑事務功能

30. 應付超大資料量

PGSQL 不能應付超大資料量，由于PGSQL本身的MVCC設計問題，需要垃圾回收，只能期待后面的大版本做優化   

  MySQL

不能應付超大資料量，MySQL自身架構的問題

31. 分布式演進

PGSQL HTAP資料庫：cockroachDB、騰訊Tbase 分片集群：  Postgres-XC、Postgres-XL

  MySQL
HTAP資料庫：TiDB
分片集群： 各種各樣的中間件，不一一列舉

32. 資料庫的檔案名和命名規律

PGSQL PGSQL在這方面做的比較不好，DBA不能在作業系統層面（停庫狀態下）看清楚資料庫的檔案名和命名規律，檔案的數量，檔案的大小 一旦作業系統發生檔案丟失或硬碟損壞，非常不利于恢復，因為連名字都不知道 PGSQL表資料物理檔案的命名/存放規律是： 在一個表空間下面，如果沒有建表空間默認在默認表空間也就是base檔案夾下，例如：/data/base/16454/3599 base：默認表空間pg_default所在的物理檔案夾
16454：表所在資料庫的oid
3599：就是表物件的oid，當然，一個表的大小超出1GB之后會再生成多個物理檔案，還有表的fsm檔案和vm檔案，所以一個大表實際會有多個物理檔案 由于PGSQL的資料檔案布局內容太多，大家可以查閱相關資料 當然這也不能全怪PGSQL，作為一個DBA，時刻做好資料庫備份和容災才是正道，做介質恢復一般是萬不得已的情況下才會做   MySQL

資料庫名就是檔案夾名，資料庫檔案夾下就是表資料檔案，但是要注意表名和資料庫名不能有特殊字符或使用中文名，每個表都有對應的frm檔案和ibd檔案，存盤元資料和表/索引資料，清晰明了，做介質恢復或者表空間傳輸都很方便

33. 權限設計

PGSQL PGSQL在權限設計這塊是比較坑爹，拋開實體權限和表空間權限，PGSQL的權限層次有點像SQL Server，db=》schema=》object 要說權限，這里要說一下Oracle，用Oracle來類比 在ORACLE 12C之前，實體與資料庫是一對一，也就是說一個實體只能有一個資料庫，不像MySQL和SQL Server一個實體可以有多個資料庫，并且可以隨意跨庫查詢 而PGSQL不能跨庫查詢的原因也是這樣，PGSQL允許建多個資料庫，跟ORACLE類比就是有多個實體（之前說的實體與資料庫是一對一） 一個資料庫相當于一個實體，因為PGSQL允許有多個實體，所以PGSQL單實體不叫一個實體，叫集簇（cluster），集簇這個概念可以查閱PGSQL的相關資料 PGSQL里面一個實體/資料庫下面的schema相當于資料庫，所以這個schema的概念對應MySQL的database   注意點：正因為是一個資料庫相當于一個實體，PGSQL允許有多個實體/資料庫，所以資料庫之間是互相邏輯隔離的，導致的問題是，不能一次對一個PGSQL集簇下面的所有資料庫做操作 必須要逐個逐個資料庫去操作，例如上面說到的安裝pg_stat_statements插件，如果您需要在PGSQL集簇下面的所有資料庫都做性能收集的話，需要逐個資料庫去執行加載命令 又例如跨庫查詢需要dblink插件或fdw插件，兩個資料庫之間做查詢相當于兩個實體之間做查詢，已經跨越了實體了，所以需要dblink插件或fdw插件，所以道理非常簡單   權限操作也是一樣逐個資料庫去操作，還有一個就是PGSQL雖然像SQL Server的權限層次結構db=》schema=》object，但是實際會比SQL Server要復雜一些，還有就是新建的表還要另外授權 在PGSQL里面，角色和用戶是一樣的，對新手用戶來說有時候會傻傻分不清，也不知道怎么去用角色，所以PGSQL在權限設計這一塊確實比較坑爹
  MySQL

使用mysql庫下面的5個權限表去做權限映射，簡單清晰，唯一問題是缺少權限角色

user表
db表
host表
tables_priv表
columns_priv表

34. 發展歷史

PGSQL
在1995年，開發人員Andrew Yu和Jolly Chen在Postgres中添加了一個SQL（Structured Query Language，結構化查詢語言）翻譯程式，該版本叫做Postgres95，在開放源代碼社區發放，
在1996年，再次對Postgres95做了較大的改動，并將其命名為PostgresSQL 6.0版發布，PostgresSQL 的名字就此定型，從1995年算起，大概有24年歷史


MySQL
在1996年，MySQL 1.0發布，它只面向一小撥人，相當于內部發布，
到了1996年10月，MySQL 3.11.1發布(MySQL沒有2.x版本)，最開始只提供Solaris作業系統下的二進制版本，一個月后，Linux版本出現
從1996年算起，大概有23年歷史

 

 

小結

上面的對比表還不是很完善，只有一些本人認為比較關鍵的特性拿出來對比

 

總的來說，兩種資料庫都有優缺點，大家在選型的時候需要謹慎選擇，MySQL需要多折騰，PGSQL讓你少折騰，因為PGSQL本身已經做的比較完善，不太需要依賴一些第三方工具

當然，如果在MySQL上選擇Percona 分支，MariaDB分支，或者Oracle官方的MySQL企業版就另當別論

MySQL因為需要支持更換存盤引擎，所以某些功能都要受制于存盤引擎層，例如：物理復制

而PGSQL不支持更換存盤引擎（在PGSQL V12開始也支持可插撥的表存取介面），而且一直由官方統一開發和維護，所以相對比較穩定，功能也比較完善，對得上它的稱號：《世界上功能最為強大的開源資料庫》

PGSQL V12 支持可插撥的表存取介面之后，有可能由第三方存盤引擎來改進PGSQL本身的MVCC實作機制，而不需要等待官方去解決，聚集索引、undo表空間這些都不再是問題

如果業務復雜的話，其實PGSQL是最佳選擇，分享一篇文章：為什么“去O”唯有PG

 

 

如有不對的地方，歡迎大家拍磚o(∩_∩)o 

本文著作權歸作者所有，未經作者同意不得轉載，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/2496.html

標籤：PostgreSQL

上一篇：SQL陳述句中的日期查詢

下一篇：SELECT陳述句基礎

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀：**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題，由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視，實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶，一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀：**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高，采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐，遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀：**滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今后的規劃。 #1. 背景 資料，對于任何一家互聯網公司來說都是非常重要的資產，公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀：**深耕人工智能領域，致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎，這次獲獎的專案是什么呢？一起來看看詳細報道吧！ 近日，由國際計算語言學協會ACL（The Association for Computational Linguistics）舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp？ MPP (Massively Parallel Processing)，即大規模并行處理，在資料庫非共享集群中，每個節點都有獨立的磁盤存盤系統和記憶體系統，業務資料根據資料庫模型和應用特點劃分到各個節點上，每臺資料節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀：**指標體系是什么？如何使用OSM模型和AARRR模型搭建指標體系？如何統一流程、規范化、工具化管理指標體系？本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標，系統化的組織起來，通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索，LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料，可以使用下面的 SQL 陳述句： SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀：**Ceph是國際知名的開源分布式存盤系統，在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統， ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章，這一次主要寫一個嵌套的聚合，例如先對sex集合，再對desc聚合，最后再對age求和，共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by，avg，sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack（ELK）部署

    傻瓜式部署，只需替換IP與用戶 導讀： 現ELK四大組件分別為：Elasticsearch（核心）、logstash（處理）、filebeat（采集）、kibana（可視化） 下載均在https://www.elastic.co/cn/downloads/下tar包，各組件版本最好一致，配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取？ 快取就是資料交換的緩沖區（稱作Cache），是存盤資料的臨時地方，一般讀寫性能較高。 快取的作用： 降低后端負載 提高讀寫效率，降低回應時間 快取的成本： 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下，當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志（binlog），我們都知道二進制日志（binlog）非常重要，尤其當你需要point to point災難恢復的時侯，所以我們要對其進行備份。關于二進制日志（binlog)的備份,可以基于flush logs方式先切換binlog，然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼： 發送驗證碼的介面為：http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式：PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能，以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景，僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼，對其進行一對一優化，而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題，盡量不要讓一個事務拖太長的時間 例如檔案上傳時，應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代，MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足，但是對于很多開發者和DBA來說，如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL（ClickHouse自帶）、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼，對其進行一對一優化，而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題，盡量不要讓一個事務拖太長的時間 例如檔案上傳時，應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“（堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError（堆外記憶體溢位) ”問題如下： 一、報錯資訊： 使用 Redis 的業務介面 ，產生 OutOfDirectMemoryError（堆外記憶體溢位），如圖： 格式化后的報錯資訊： { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取？ 快取就是資料交換的緩沖區（稱作Cache），是存盤資料的臨時地方，一般讀寫性能較高。 快取的作用： 降低后端負載 提高讀寫效率，降低回應時間 快取的成本： 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下，當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼： 發送驗證碼的介面為：http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式：PO ......

    uj5u.com 2023-04-20 08:23:11 more

Copyright © 2010-2020 有解無憂