mysql數據庫未來展望（數據庫發展前景）

本文目錄一覽：

1、新一代HTAP數據庫崛起，MySQL生態的最佳歸宿？
2、mysql還有發展前景嗎？
3、請問各位前輩目前主流數據庫有哪些？各自未來的前景怎樣？望專門說說mysql的現狀、前途。
4、mysql編碼數據庫，數據表，字段各用什麼編碼
5、mysql數據庫怎麼優化，有幾方面的優化

新一代HTAP數據庫崛起，MySQL生態的最佳歸宿？

俗話說，天下大勢，合久必分、分久必合。

數據庫領域同樣如此。過去五十餘年，數據庫經歷OLTP和OLAP兩種需求漫長的融合-分離-再融合的過程。究其原因，數據庫的發展始終與用戶場景需求變遷緊密相關。如今，隨着雲計算和大數據的興起，業務場景正在經歷前所未有的變革，數據庫領域也掀起了一股HTAP浪潮。

Gartner在多次報告中強調，HTAP是數據庫領域最重要的發展趨勢之一，也是用戶數字化轉型中重要的數據平台。業界甚至認為，HTAP的興起代表着數據庫大融合時代的開啟。

那麼，為什麼數據庫大廠和雲服務巨頭們均紛紛押寶HTAP？開源+多云為何是HTAP普及的助推劑？面對新一代HTAP數據的崛起，多年積累形成的MySQL生態終於找到最佳歸宿？

放在幾年前，HTAP可能還會被認為是數據庫領域的小眾產品，是否成氣候還有待觀察。

而隨着數據資源、數據消費習慣和數據驅動型場景發生巨大變化，用戶需求與傳統數據庫之間的供需矛盾日漸突出，使得HTAP這種具備「同時支持OLTP和OLAP、創新計算存儲框架、去ETL」等特徵的新時代數據庫成為不可阻擋的趨勢。

如今，幾乎所有數據庫大廠和雲服務巨頭都在布局HTAP。例如，OceanBase去年推出的 3.0版本中就正式宣布向HTAP數據庫進軍；今年5月，Google Cloud發佈HTAP雲端數據庫AlloyDB，為PG用戶提供了HTAP數據庫服務；再加上Oracle MySQL Heatwave，甚至連SnowFlake也發佈Unistore來「蹭」HTAP的熱點。

如果細數近一年以來的HTAP新品，會發現幾乎全部都建立在雲端之上。新一代HTAP+雲正在成為數據庫市場重要的潮流。例如，PingCAP近日發佈的TiDB 6.0，也是與雲端緊密聯繫的新一代HTAP數據庫。

事實上，PingCAP是HTAP數據庫領域非常重要的一個引領者。早在TiDB 3.0起，PingCAP就正式轉向HTAP，從OLTP主引擎+OLAP輔助能力，到OLTP引擎+外接分析引擎，再到OLTP引擎+融合分析引擎，PingCAP在HTAP領域穩打穩紮，一個版本上一個台階。

如今，隨着TiDB 6.0的發佈，針對HTAP進行了更多成熟性改進，TPC-C 性能也較 5.0 版本提升達到 76.32%，TiDB 6.0還增強了多個企業級特性，以更好適合雲時代用戶對於HTAP數據庫的需求。

固然，有人質疑當前HTAP是新瓶裝舊酒，並無太多新意。但業界普遍形成共識：新一代HTAP與過去完全不同，開源+雲孕育而出，很多都有AI加持，而且是為數據敏捷而生，擁有過去前所未有的創新活力與迭代速度，並逐漸形成數據庫技術變革的新潮流。

PingCAP CTO 黃東旭也直言：「TiDB近年來的快速進化與迭代，得益於開源和雲的助力。」

HTAP之所受到用戶青睞，某種程度是因為用戶對於數據敏捷性的極度渴求。

「在數字化時代，客戶最為在乎的是如何快速走向市場。這需要數據敏捷性，而HTAP恰恰是數據敏捷的核心能力。」黃東旭如是說。

最近幾年，「海量、實時、在線」的需求越來越廣泛，大量採用 MySQL 和 PostgreSQL 開源數據庫的新一代企業需要提升對於熱數據的實時在線分析能力，這類需求遍布幾乎所有的互聯網企業以及從事線上業務的數字化轉型企業。對於新鮮數據的實時分析能力直接決定了這些業務的生死存亡，傳統的 OLTP+OLAP+ETL 的數據架構已經嚴重阻礙了消費者體驗，這種訴求催生了 HTAP 的技術變革。

而真正幫助HTAP與用戶需求完成對接的則是開源+雲。眾所周知，開源近年來在數據庫領域的流行和影響力與日俱增，DB-Engines數據顯示，全球383款數據庫中開源數據庫佔據51.7%，六款開源數據庫進入到前十，開源正在成為像HTAP這種新時代數據庫的創新源泉。

以PingCAP的TiDB為例，其產品研發體系建立在開源體系和開源社區的基礎上，實現了一年一個大版本、一個月一個小版本的迭代速度。黃東旭透露道：「開源是TiDB的第一個增長引擎，通過開源體系，開發者、貢獻者、佈道者和用戶能夠很好串聯起來，形成飛輪效應，讓產品能夠走向加速迭代和創新的正向循環。」

據悉，TiDB每年會有超過 40% 的代碼更新，而這些代碼有很大一部分由外部貢獻者所共享。TiDB開源項目一直在全球和中國開源項目活躍度中名列前茅。

如果說開源改變了HTAP產品的開發模式和迭代速度，那麼雲則能夠為HTAP產品提供用戶最為直接的需求反饋。眾所周知，雲數據庫一改以往傳統數據庫部署、運維、擴展等難題，以雲服務的方式讓數據庫使用更加簡單；更加關鍵的是，隨着雲計算的普及，雲上用戶群體持續增加，來自雲上用戶群體的需求反饋無時無刻都在發生，對於數據庫產品的進化與迭代至關重要。

「真正的產品迭代是如何縮短用戶問題/需求的反饋時間。雲無疑為數據庫等基礎軟件提供了這樣的價值，讓產品可以更好地迭代。」黃東旭如是說。以TiDB為例，自去年五月全託管的數據庫即服務（DBaaS）產品 TiDB Cloud 公測版發佈以來，已經陸續登陸亞馬遜雲科技、谷歌雲等全球知名雲服務商的Marketplace，並在今年5月份正式全球商用；今年 6 月與阿里雲合作上線阿里云云市場，成為為數不多的跨全球三朵雲的數據庫服務。

在眾多數據庫產品之中，MySQL憑藉著開源、免費、適合互聯網場景等優勢，常年位居全球最受歡迎數據庫的前三。根據Slintel網站的統計數據，在全球關係型數據庫市場中，MySQL市場份額最高，達到43.04%。

過去二十年里，開源MySQL數據庫對於各行各業影響至深，捕獲了來自互聯網、金融、零售、交通等多個行業用戶的心，堪稱「萬人迷」。例如，在中國就有超過9成的金融機構都應用了MySQL數據庫。

但任何數據庫潮流都是「需求變化+技術變革+架構創新」融合的產物，MySQL是如此，HTAP亦不例外。如今，場景的數據規模、業務並發量、處理速度要求跟以往相比早已不是一個數量級。此時，MySQL數據庫的局限性愈發突出，擴展性很難滿足用戶需求，想繼續獲得增長的企業不得不使用分庫分表方案，但這又會造成數據架構的複雜性。

新一代HTAP數據庫無需分庫分表，且具備實時海量規模的OLTP和實時數據分析能力，還擁有極為出色的擴展性，與很多業務場景的海量交易實時數據展現、平穩運行的需求高度契合，HTAP憑藉技術架構優勢崛起已成必然。

「用戶需求側最大的變化就是很多用戶需要藉助熱數據實現運營級別的實時分析，獲得實時洞察以支持決策，這極大推動了新一代HTAP數據庫的需求。」PingCAP副總裁劉松補充道。

雖然MySQL已經增加列存引擎Heatwave來獲得HTAP能力，但主要解決規模化查詢的問題，系統本身架構並未產生革命性變化，擴展能力、OLTP吞吐量依然有着很大局限。「智能新能源汽車跟傳統燃油車在外表看幾乎沒區別。數據庫也類似，像TiDB這種新一代HTAP數據庫，從架構設計、應對場景和使用體驗等角度，都與傳統數據庫有着極大的區別。」劉松形象比喻道。

事實上，與過去SAP HANA這種小眾、昂貴的HTAP不同，新一代HTAP擁有極強的兼容性，像Google Cloud、PingCAP這些數據庫廠商都藉助新一代HTAP架構為採用 MySQL或者PG開源數據庫的企業拓展 OLTP和OLAP的能力範圍。

例如，Google Cloud發佈的HTAP雲端數據庫AlloyDB，為單機版PG生態用戶提供了最好選擇，TiDB則成為MySQL生態的最佳歸宿。PingCAP大量用戶中有很多TiDB與MySQL混合部署的成功案例；得益於 TiDB 的開放性，TiDB 也可通過和其他數據服務產品「混搭」形成新的數據服務解決方案，如通過同樣是開源的大數據計算引擎 Flink 混搭形成實時數倉解決方案，擴展 HTAP 數據庫的能力邊界。

黃東旭則直言，HTAP數據庫除了產品、技術之外，尤為需要關心用戶體驗，「HTAP應該讓用戶覺得好用，屏蔽掉數據庫的複雜性。」據悉，PingCAP是2022 Gartner Peer Insights「Voice of the Customer」雲數據庫領域唯一入選的中國數據庫公司，客戶總體評分達到 4.7 分（滿分 5 分），在所有入選企業中位列第一。在參與Gartner Peer Insights評分的PingCAP用戶中，像互聯網、金融等重點行業用戶均高度認可HTAP現代數據庫理念。

總體來看，今年是HTAP的大年，各大廠商紛紛在市場中上新。隨着新一代HTAP數據庫產品的增多，整個市場對於HTAP數據庫理念和產品的接受與採用將會提速。而隨着新一代HTAP數據庫持續完善，讓廣大MySQL生態用戶群真正看到了大數據時代一條絕佳的遷移路徑。

mysql還有發展前景嗎？

我們看看現在世界上一流的互聯網公司，前20強中的Yahoo（MySQL用戶）、Google（MySQL用戶）、Youtube（MySQL用戶）、WIN Live（MS SQL Server）、Facebook（MySQL用戶）、MSN（MS SQL Server）、Wikipedia（MySQL用戶）、Blogger（MySQL用戶）、MySpace（不知道）、Yohoo.co.jp（MySQL用戶）、Baidu（MySQL用戶）、Google.co.in（MySQL用戶）、google.de（MySQL用戶）、Microsoft（MS SQL Server）、Rapidshare（MySQL用戶）、QQ.com（MySQL用戶）、Google.fr（MySQL用戶）、Sina.com.cn（MySQL用戶）、Ebay（MySQL用戶）、Fc2.com（MySQL用戶），看看這些著名的公司吧。國內的大的互聯網公司，找不到沒有用MySQL數據庫的。前段時間，很多獵頭公司找MySQL的高手都很難。

MySQL的確已成為全球最受歡迎的開源數據庫，Oracle收購後也必須順應市場的潮流、順應客戶的需求，因此，這個產品的前途無量啊。

試想，QQ每天巨大的業務量，還涉及Q幣、充值等等交易系統，MySQL完全勝任了它所有的業務。

Oracle不僅對MySQL產品做出了十大承諾，事實上，最近一系列的具體措施也證明Oracle將會使MySQL更美好！Oracle is now making MySQL better！

九月份在美國舉行的Open OneWorld上有MySQL專場，今年12月份該活動在北京舉行，也有MySQL活動的專場。

在產品發展路線上，Oracle預計在今年年底推出MySQL 5.5版本，其默認存儲引擎將變為性能更加突出的Innodb，據初步評測，性能有近10倍的提升。Oracle增強了一系列MySQL企業級特性和工具，包含MySQL Monitor、Workbench GUI Tools、Cluster產品等等。

在市場競爭定位上，MySQL產品被主要定位於三大領域：Web、Telecom和Embed，事實上，這些也並不是原有Oracle的突出優勢市場。目前，在大中國區，Oracle對MySQL產品已經成立了獨立的銷售團隊，在國內有上海愛可生成為本地化服務和總分銷支持。

一切看來，這個產品是符合市場需求的，Oracle這家市場運營的高手，會把一個很有市場前景的產品雪藏嗎？答案是肯定不會的。

去精通MySQL吧，未來一定前途無量；阿里雲、盛大雲、中移動雲、虛擬化等等有太多新的技術與MySQL相關；移動互聯網、三網融合應用不斷發展創造着越來越多的MySQL新機會。

還擔心什麼呢？大膽採用開源理念，選擇最專業的合作夥伴去創新你的系統和業務吧！選擇開源MySQL作為數據庫平台是符合未來的發展趨勢的，其跨平台、開放性、易用性和低的總體擁有成本TCO都是符合企業應用需求的。

請問各位前輩目前主流數據庫有哪些？各自未來的前景怎樣？望專門說說mysql的現狀、前途。

目前比較流行數據庫：

sqlserver和oracle數據庫是比較常用的，且用於管理大型數據的。主流如下：微軟：sql server 和 access；瑞典MySQL：AB公司 mysql；IBM公司：db2；美國Sybase公司：Sybase；IBM公司：informix；美國oracle公司：oracle；小型數據庫：access、foxbase；中型數據庫：sql server 、mysql、informix；大型數據庫：db2、Oracle、Sybase。

後半部分無法回答，看個人發展方向，希望對你有用。

mysql編碼數據庫，數據表，字段各用什麼編碼

1. ASCII

用途：用來映射簡單的單位元組字符，比如大小寫英文字母、阿拉伯數字、常用的標點符、運算符、控制字符等。

編碼範圍：U+0000 – U+007F

注意：對於用這類字符的場景夠用了，但是卻無法表達比如漢字，日文等編碼。

2. UNICODE

用途：用來映射包含 ASCII 以內的其他的所有字符。

編碼範圍：U+0000 – U+10FFFF

注意：ASCII 是 UNICODE 的子集，ASCII 編碼的字符可以無損轉換為 UNICODE 編碼的字符。

MySQL 常用字符集

1. Latin1

Latin1 是 cp1252 或者 ISO-8859-1 的別名。ISO-8859-1 編碼是單位元組編碼，向下兼容 ASCII。

編碼範圍：U+0000 – U+00FF

ISO-8859-1 收錄的字符除 ASCII 收錄的字符外，還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字符號。

單位元組內的空間都被 ISO-8859-1 編碼佔用，所以能夠用 ISO-8859-1 編碼存儲、傳輸其他任何編碼的位元組流。

比如把一個 Utf8mb4 的編碼或者 GBK 的編碼存入 Latin1，不會有任何問題。因為 Latin1 保留了原始的位元組流，這也就是 MySQL 長期以來把 Latin1 做默認字符集的原因。

但是由於 Latin1 對任何字符都存放位元組流，造成了字符個數的浪費。

比如：

CHAR(10) CHARACTER SET LATIN1;CHAR(10) CHARACTER SET UTF8;

該字段中存儲字符個數 UTF8 是 Latin1 的三倍！！！

2. GB18030

GB18030 是中國官方標準字符集，向前兼容 GBK、GB2312，是這兩個的超集。用 1、2、4 個位元組分別表示一個符號。比如對一般中文字符，默認是用兩個位元組編碼存儲。Windows 系統，默認用的就是 GB18030。

若只是存儲中文字符，那 GB18030 最佳。

原因有兩點：

1）佔用空間小，比如比 UTF8 小。

2）存儲的漢字根據拼音來排序，檢索快。

3. UTF8

UTF8 是 Unicode 的編碼實現，可以存儲 UNICODE 編碼對應的任何字符，這也是使用最多的一種編碼。最大的特點就是變長的編碼方式，用 1 到 4 個位元組表示一個符號，可以根據不同的符號編碼位元組長度。

字母或數字用 1 位元組，漢字用 3 位元組，emoji 表情符號用 4 位元組。UTF8 字符集目前是使用最廣泛的。

注意！MySQL 里常說的 UTF8 是 UTF8MB3 的別名，UTF8MB3 是 UTF8MB4 的子集，UTF8MB4 才是真正的 4 位元組 UTF8 字符集！

UTF8MB3 表示最大支持 3 個位元組存儲字符，UTF8MB4 表示最大 4 個位元組存儲字符。根據實際需要和未來展望，MySQL 8.0 已經默認用 UTF8MB4 基礎字符集。

mysql數據庫怎麼優化，有幾方面的優化

在開始演示之前，我們先介紹下兩個概念。

概念一，數據的可選擇性基數，也就是常說的cardinality值。

查詢優化器在生成各種執行計劃之前，得先從統計信息中取得相關數據，這樣才能估算每步操作所涉及到的記錄數，而這個相關數據就是cardinality。簡單來說，就是每個值在每個字段中的唯一值分佈狀態。

比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數可以是100個，也可以是1個，當然也可以是1到100之間的任何一個數字。這裡唯一值越的多少，就是這個列的可選擇基數。

那看到這裡我們就明白了，為什麼要在基數高的字段上建立索引，而基數低的的字段建立索引反而沒有全表掃描來的快。當然這個只是一方面，至於更深入的探討就不在我這篇探討的範圍了。

概念二，關於HINT的使用。

這裡我來說下HINT是什麼，在什麼時候用。

HINT簡單來說就是在某些特定的場景下人工協助MySQL優化器的工作，使她生成最優的執行計劃。一般來說，優化器的執行計劃都是最優化的，不過在某些特定場景下，執行計劃可能不是最優化。

比如：表t1經過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經很不準確了，這時候剛好執行了一條SQL，那麼有可能這條SQL的執行計劃就不是最優的。為什麼說有可能呢？

來看下具體演示

譬如，以下兩條SQL，

A：

select * from t1 where f1 = 20;

B：

select * from t1 where f1 = 30;

如果f1的值剛好頻繁更新的值為30，並且沒有達到MySQL自動更新cardinality值的臨界值或者說用戶設置了手動更新又或者用戶減少了sample page等等，那麼對這兩條語句來說，可能不準確的就是B了。

這裡順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。

那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。

示例表結構：

mysql desc t1;+————+————–+——+—–+———+—————-+| Field | Type | Null | Key | Default | Extra |+————+————–+——+—–+———+—————-+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+————+————–+——+—–+———+—————-+7 rows in set (0.00 sec)

表記錄數：

mysql select count(*) from t1;+———-+| count(*) |+———-+| 32768 |+———-+1 row in set (0.01 sec)

這裡我們兩條經典的SQL：

SQL C：

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;

表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。

那我們來看SQL C的查詢計劃。

顯然，沒有用到任何索引，掃描的行數為32034，cost為3243.65。

mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “3243.65” }, “table”: { “table_name”: “t1”, “access_type”: “ALL”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “rows_examined_per_scan”: 32034, “rows_produced_per_join”: 115, “filtered”: “0.36”, “cost_info”: { “read_cost”: “3232.07”, “eval_cost”: “11.58”, “prefix_cost”: “3243.65”, “data_read_per_join”: “49K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)

我們加上hint給相同的查詢，再次看看查詢計劃。

這個時候用到了index_merge,union了三個列。掃描的行數為1103，cost為441.09，明顯比之前的快了好幾倍。

mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “441.09” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “union(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1103, “rows_produced_per_join”: 1103, “filtered”: “100.00”, “cost_info”: { “read_cost”: “330.79”, “eval_cost”: “110.30”, “prefix_cost”: “441.09”, “data_read_per_join”: “473K” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))” } }}1 row in set, 1 warning (0.00 sec)

我們再看下SQL D的計劃：

不加HINT，

mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “534.34” }, “table”: { “table_name”: “t1”, “access_type”: “ref”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “idx_rank1”, “used_key_parts”: [ “rank1” ], “key_length”: “5”, “ref”: [ “const” ], “rows_examined_per_scan”: 555, “rows_produced_per_join”: 0, “filtered”: “0.07”, “cost_info”: { “read_cost”: “478.84”, “eval_cost”: “0.04”, “prefix_cost”: “534.34”, “data_read_per_join”: “176” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))” } }}1 row in set, 1 warning (0.00 sec)

加了HINT，

mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { “query_block”: { “select_id”: 1, “cost_info”: { “query_cost”: “5.23” }, “table”: { “table_name”: “t1”, “access_type”: “index_merge”, “possible_keys”: [ “idx_rank1”, “idx_rank2”, “idx_rank3” ], “key”: “intersect(idx_rank1,idx_rank2,idx_rank3)”, “key_length”: “5,5,5”, “rows_examined_per_scan”: 1, “rows_produced_per_join”: 1, “filtered”: “100.00”, “cost_info”: { “read_cost”: “5.13”, “eval_cost”: “0.10”, “prefix_cost”: “5.23”, “data_read_per_join”: “440” }, “used_columns”: [ “id”, “rank1”, “rank2”, “log_time”, “prefix_uid”, “desc1”, “rank3” ], “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))” } }}1 row in set, 1 warning (0.00 sec)

對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。

總結下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。

原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/246857.html