整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
.你是如何理解HTML語義的？
答：使用合適的標(biāo)簽標(biāo)示內(nèi)容。優(yōu)點(diǎn)在于標(biāo)簽語義化有利于搜索引擎建立索引進(jìn)行抓 取，有助于構(gòu)建良好的HTML結(jié)構(gòu)，便于團(tuán)隊(duì)開發(fā)和維護(hù)。
2.meta viewport 是做什么用的，怎么寫？
答：meta表示不能被HTML的其它元素（link，script,base, style, title）之一表示的任何元素信息。viewpoint讓web開發(fā)者控制視口的尺寸及比例，移動設(shè)備的viewpoint指設(shè)備屏幕上用來展示網(wǎng)頁的那一塊區(qū)域，也就是瀏覽器上用來展示網(wǎng)頁的那部分，可能比瀏覽器的可視區(qū)大，也可能比瀏覽器可視區(qū)域小，一般情況，比瀏覽器可視區(qū)域大。屬性包括width、height、initial-scale、maximum-scale、minimum-scale,使用方式是
<meta name="viewpoint" content="width=device-width, initial-scale=1, maximum-scale=1">
3.canvas 元素是干什么的？
答： canvas是用來繪制圖形的HTML元素。
4.html5新特性？如何處理HTML5新標(biāo)簽的瀏覽器兼容問題？如何區(qū)分 HTML 和 HTML5？
答：html5新特性：
解決兼容性的方法：
<!--[if lt IE 9]> <script> src="http://html5shim.googlecode.com/svn/trunk/html5.js"</script> <![endif]-->
HTML和HTML5
html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
html5:
<!doctype html>
<div id="header"></div>
html5: 具有結(jié)構(gòu)語義
<header></header>
5.Doctype作用？標(biāo)準(zhǔn)模式與兼容模式各有什么區(qū)別?
答： Doctype是document type(文檔類型)，告訴瀏覽器解析器采用哪種規(guī)范（html、xhtml）來解析頁面，Doctype不存在或格式錯(cuò)誤的情況下，采用兼容模式。
標(biāo)準(zhǔn)模式（嚴(yán)格模式）展示的支持最新標(biāo)準(zhǔn)的網(wǎng)頁。兼容模式（松散模式或怪異模式）展示的是兼顧傳統(tǒng)瀏覽器的網(wǎng)頁，向后兼容老式瀏覽器。
具體區(qū)別：
6.用戶訪問頁面到最終渲染的整個(gè)過程？
用戶輸入url,瀏覽器向服務(wù)器發(fā)送請求，獲取html,然后進(jìn)入HTML渲染機(jī)制。首先，根據(jù)HTML生成DOM樹；其次，根據(jù)css和js重排頁面 https://segmentfault.com/a/1190000009317496
7.你對頁面進(jìn)行性能優(yōu)化的思路和思想是什么？
答： 減少http請求; 減少DOM操作，避免不必要的重繪和重排;壓縮文件體積；采用CDN；
在實(shí)際的生產(chǎn)環(huán)境中，一個(gè)field的設(shè)置是不能被修改的，如果要修改一個(gè)Field，那么應(yīng)該重新按照新的mapping，建立一個(gè)index，然后將數(shù)據(jù)批量查詢出來，重新用bulk api寫入index中。
批量查詢的時(shí)候，建議采用scroll api，并且采用多線程并發(fā)的方式來reindex數(shù)據(jù)。例如說每次scoll就查詢指定日期的一段數(shù)據(jù)，交給一個(gè)線程即可。
(1) 一開始，依靠dynamic mapping，插入數(shù)據(jù)，但是不小心有些數(shù)據(jù)是2019-09-10這種日期格式的，所以title這種field被自動映射為了date類型，實(shí)際上它應(yīng)該是string類型的。
首先插入以下數(shù)據(jù)
PUT /my_index/_doc/1
{
"title": "2019-09-10"
}
PUT /my_index/_doc/2
{
"title": "2019-09-11"
}（2）當(dāng)后期向索引中加入string類型的title值的時(shí)候，就會報(bào)錯(cuò)
PUT /my_index/_doc/3
{
"title": "my first article"
}報(bào)錯(cuò)
{
"error": {
"root_cause": [
{
"type": "mapper_parsing_exception",
"reason": "failed to parse field [title] of type [date] in document with id '3'. Preview of field's value: 'my first article'"
}
],
"type": "mapper_parsing_exception",
"reason": "failed to parse field [title] of type [date] in document with id '3'. Preview of field's value: 'my first article'",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "failed to parse date field [my first article] with format [strict_date_optional_time||epoch_millis]",
"caused_by": {
"type": "date_time_parse_exception",
"reason": "Failed to parse with all enclosed parsers"
}
}
},
"status": 400
}（3）如果此時(shí)想修改title的類型，是不可能的
PUT /my_index/_mapping
{
"properties": {
"title": {
"type": "text"
}
}
}報(bào)錯(cuò)
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "mapper [title] of different type, current_type [date], merged_type [text]"
}
],
"type": "illegal_argument_exception",
"reason": "mapper [title] of different type, current_type [date], merged_type [text]"
},
"status": 400
}（4）此時(shí)，唯一的辦法，就是進(jìn)行reindex，也就是說，重新建立一個(gè)索引，將舊索引的數(shù)據(jù)查詢出來，再導(dǎo)入新索引。
（5）如果說舊索引的名字，是old_index，新索引的名字是new_index，終端java應(yīng)用，已經(jīng)在使用old_index在操作了，難道還要去停止java應(yīng)用，修改使用的index為new_index，才重新啟動java應(yīng)用嗎？這個(gè)過程中，就會導(dǎo)致java應(yīng)用停機(jī)，可用性降低。
（6）所以說，給java應(yīng)用一個(gè)別名，這個(gè)別名是指向舊索引的，java應(yīng)用先用著，java應(yīng)用先用prod_index來操作，此時(shí)實(shí)際指向的是舊的my_index
PUT /my_index/_alias/prod_index（7）查看別名，會發(fā)現(xiàn)my_index已經(jīng)存在一個(gè)別名prod_index了。
GET my_index/_alias（8）新建一個(gè)index，調(diào)整其title的類型為string
PUT /my_index_new
{
"mappings": {
"properties": {
"title": {
"type": "text"
}
}
}
}（9）使用scroll api將數(shù)據(jù)批量查詢出來
GET /my_index/_search?scroll=1m
{
"query": {
"match_all": {}
},
"size": 1
}返回
{
"_scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAARUMWQWx5bzRmTW9TeUNpNmVvN0E2dF9YQQ==",
"took" : 4,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "my_index",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"title" : "2019-09-10"
}
}
]
}
}
（9）采用bulk api將scoll查出來的一批數(shù)據(jù)，批量寫入新索引
POST /_bulk
{"index":{"_index":"my_index_new","_id":"1"}}
{"title":"2019-09-10"}（10）反復(fù)循環(huán)8~9，查詢一批又一批的數(shù)據(jù)出來，采取bulk api將每一批數(shù)據(jù)批量寫入新索引
（11）將my_index索引的別名prod_index切換到my_index_new上去，java應(yīng)用會直接通過index別名使用新的索引中的數(shù)據(jù)，java應(yīng)用程序不需要停機(jī)，零提交，高可用
POST /_aliases
{
"actions": [
{
"remove": {
"index": "my_index",
"alias": "prod_index"
}
},
{
"add": {
"index": "my_index_new",
"alias": "prod_index"
}
}
]
}（12）直接通過prod_index別名來查詢，是否ok
GET prod_index/_search可以看到能夠查詢到新索引my_index_new的數(shù)據(jù)了
{
"took" : 1117,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "my_index_new",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"title" : "2019-09-10"
}
}
]
}
}
基于alias對client透明切換index
PUT /my_index_v1/_alias/my_indexclient對my_index進(jìn)行操作
reindex操作，完成之后，切換v1到v2
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}原文地址：https://www.cnblogs.com/xiaoyh/p/16028045.html
????此賬號為華為云開發(fā)者社區(qū)官方運(yùn)營賬號，提供全面深入的云計(jì)算前景分析、豐富的技術(shù)干貨、程序樣例，分享華為云前沿資訊動態(tài)
本文分享自華為云社區(qū)《GaussDB(for MySQL)如何快速創(chuàng)建索引？華為云數(shù)據(jù)庫資深架構(gòu)師為您揭秘》，作者：華為云數(shù)據(jù)庫資深架構(gòu)師蘇斌。
蘇斌，華為云數(shù)據(jù)庫資深架構(gòu)師，擁有16年數(shù)據(jù)庫內(nèi)核研發(fā)經(jīng)驗(yàn)，之前作為MySQL官方InnoDB團(tuán)隊(duì)主要研發(fā)人員，參與和主導(dǎo)了多個(gè)重要特性的開發(fā)和發(fā)布。目前在華為公司負(fù)責(zé)和參與華為云RDS主要產(chǎn)品RDS for MySQL和GaussDB(for MySQL)內(nèi)核功能的設(shè)計(jì)和研發(fā)。
我們都知道，數(shù)據(jù)庫使用索引技術(shù)加快數(shù)據(jù)的查詢。MySQL數(shù)據(jù)庫也支持若干種索引結(jié)構(gòu)提高查詢的性能（參見MySQL文檔：https://dev.mysql.com/doc/refman/8.0/en/create-index.html），其中使用最廣泛的是B+tree索引，因?yàn)锽+tree索引在查詢和修改的性能之間有很好的平衡，同時(shí)其存儲和維護(hù)的代價(jià)也是比較優(yōu)的。
MySQL的表本身由聚簇索引（必須是B+tree索引）表示，再加上若干個(gè)二級索引，包括B+tree索引，共同組成一個(gè)MySQL的獨(dú)立表，可以說MySQL的表是由一組索引共同組成的。我們都知道索引是一把雙刃劍，充分的索引可以更好地提升可以適配的查詢的性能，但是需要維護(hù)這些索引使得其和數(shù)據(jù)同步，所以在數(shù)據(jù)修改操作階段，更多的索引也會帶來更高的開銷。索引創(chuàng)建與否的權(quán)衡通常是動態(tài)的，用戶不一定能做到在表定義之初就知道需要建立哪些索引，需要隨著業(yè)務(wù)的發(fā)展變化而調(diào)整索引，這也帶來了動態(tài)索引創(chuàng)建的一些問題。
我們先看一下MySQL索引創(chuàng)建的邏輯。首先，MySQL索引的創(chuàng)建可以使用兩種不同的DDL（Data Definition Language: 數(shù)據(jù)定義語言）算法來實(shí)現(xiàn)。第一種是COPY算法，它非常低效，就是在兩個(gè)表之間進(jìn)行數(shù)據(jù)拷貝，來完成表結(jié)構(gòu)相關(guān)的修改，尤其是它要求加表鎖，現(xiàn)在基本不使用了。第二種是INPLACE算法，該算法不要求加鎖，因此很多DDL操作是不阻塞DML（Data ManipulationLanguage: 數(shù)據(jù)操縱語句）操作的，比如創(chuàng)建索引。該算法具體的實(shí)現(xiàn)在存儲引擎層面完成，可以進(jìn)行更多的優(yōu)化。實(shí)際上DDL語句還有一種INSTANT算法，但是它無法支持創(chuàng)建索引操作，這里不展開介紹。
對于INPLACE算法，在5.7版本之前，是采用索引記錄不斷地向建好的空索引插入的方式。由于插入的數(shù)據(jù)的無序性，該方法導(dǎo)致了明顯的性能問題和潛在的空間浪費(fèi)。在5.7版本以后，MySQL優(yōu)化了建索引步驟，將其改進(jìn)為對已排序的索引記錄進(jìn)行自底向上批量插入并且緊湊拼裝的創(chuàng)建方式，如果有多個(gè)索引要?jiǎng)?chuàng)建，會單獨(dú)對每個(gè)索引執(zhí)行相同的算法。新的算法會經(jīng)歷讀取數(shù)據(jù)、排序數(shù)據(jù)和創(chuàng)建索引這幾個(gè)主要步驟。
總體而言，創(chuàng)建索引這類DDL操作，會比普通的DML等操作要費(fèi)時(shí)，而該類DDL耗時(shí)會導(dǎo)致用戶在繼續(xù)動態(tài)添加索引加速查詢的時(shí)候，需要等待很長的時(shí)間，極大影響業(yè)務(wù)；而且用戶的MySQL實(shí)例開啟了Binlog復(fù)制，耗時(shí)的DDL操作容易引起備庫的長時(shí)間落后。
MySQL的創(chuàng)建索引流程圖
隨著越來越多用戶把數(shù)據(jù)托管在云服務(wù)上，以及用戶數(shù)據(jù)量的不斷增長，前述的動態(tài)添加索引導(dǎo)致的問題非常影響用戶體驗(yàn)。同時(shí)客戶的單表數(shù)據(jù)逐漸達(dá)到幾TB甚至幾十TB，客戶對創(chuàng)建索引太慢所帶來的性能問題的抱怨越來越多，尤其是創(chuàng)建索引周期如果太長，我們可能很難找到一段合適的業(yè)務(wù)低峰期來動態(tài)創(chuàng)建索引，避免業(yè)務(wù)的波動。因此，如何在云服務(wù)環(huán)境下，解決客戶基于大量數(shù)據(jù)創(chuàng)建索引的性能問題，成為云服務(wù)廠商的一個(gè)挑戰(zhàn)。
在云化場景下，還有一個(gè)主要場景對客戶的體驗(yàn)非常重要。我們知道客戶的業(yè)務(wù)要遷移上云，需要對數(shù)據(jù)進(jìn)行大規(guī)模的遷移（華為云提供了數(shù)據(jù)復(fù)制服務(wù)DRS工具支持各類數(shù)據(jù)遷移場景），數(shù)據(jù)遷移比較高效的方式為：
1)邏輯導(dǎo)出源端數(shù)據(jù)
2)在目標(biāo)端建表（注意，表不含二級索引）
3)將源端導(dǎo)出的數(shù)據(jù)插入到目標(biāo)端
4)對目標(biāo)端的表建立二級索引
如果涉及動態(tài)數(shù)據(jù)同步，相關(guān)步驟會更復(fù)雜一些，由于和該主題無關(guān)，這里不展開。以上步驟中，需要重點(diǎn)注意的是步驟2和4，在目標(biāo)端創(chuàng)建表的時(shí)候先不創(chuàng)建二級索引。這個(gè)優(yōu)化對性能影響很大，尤其是一個(gè)表有很多二級索引的場景。我們知道Btree索引的插入如果是有序的，對插入性能和結(jié)果的空間利用率是最好的，因?yàn)锽tree索引的分裂會在插入?yún)^(qū)域的尾部產(chǎn)生，同時(shí)由于分裂算法的優(yōu)化，分裂產(chǎn)生的頁面填充率會比較高；相反地，如果是隨機(jī)插入，尤其是并發(fā)地隨機(jī)插入，很容易導(dǎo)致Btree索引在不同的節(jié)點(diǎn)進(jìn)行分裂，并且分裂后的頁面填充率都處于一個(gè)半滿的狀態(tài)，導(dǎo)致Btree最終的一個(gè)膨脹。
有了這個(gè)背景之后，我們就容易理解上面的問題，插入表數(shù)據(jù)的時(shí)候，我們屏蔽了二級索引，等所有數(shù)據(jù)都準(zhǔn)備好了，再采用批量建立索引的方式創(chuàng)建二級索引，這對于二級索引創(chuàng)建效率是最高的。如果不這么做，每插入一條記錄，就要去插入相應(yīng)的二級索引，那么二級索引就是一個(gè)無序的隨機(jī)插入，并發(fā)起來性能會變差很多。
雖然在數(shù)據(jù)同步準(zhǔn)備好后，批量創(chuàng)建二級索引是一個(gè)有效的方案，但是如果數(shù)據(jù)量很大，這么創(chuàng)建二級索引還是非常耗時(shí)，導(dǎo)致客戶在數(shù)據(jù)遷移完之后需要等待很長時(shí)間才能開展業(yè)務(wù)，這個(gè)等待周期可能是小時(shí)甚至天級別的。雖然可以考慮表級別的并發(fā)創(chuàng)建索引，但是這個(gè)方法也有明顯的缺點(diǎn)：應(yīng)用場景有限，要求有多表；以及表和表之間的并發(fā)其實(shí)不是一個(gè)最有效的并發(fā)形式，相互影響比較大。
綜上所述，在創(chuàng)建索引這個(gè)點(diǎn)上存在兩個(gè)性能瓶頸點(diǎn)：一個(gè)是用戶遷移數(shù)據(jù)之后的批量索引創(chuàng)建；第二個(gè)是用戶臨時(shí)需要添加一個(gè)二級索引。無論哪個(gè)點(diǎn)，我們都需要更快的建立好索引，提升用戶的使用體驗(yàn)。
華為云GaussDB(for MySQL)引入了并行創(chuàng)建索引的技術(shù)，它改進(jìn)了社區(qū)版MySQL創(chuàng)建索引只用單線程的問題，以此提高創(chuàng)建索引的效率，并一起解決了前述兩個(gè)痛點(diǎn)。前面提到的社區(qū)版創(chuàng)建索引邏輯是單線程的，首先存在資源利用率不夠飽滿的問題；其次創(chuàng)建索引過程是CPU和IO開銷交替進(jìn)行的過程，在做一個(gè)操作的時(shí)候，即使不是資源競爭的操作也只有等待。多線程創(chuàng)建索引可以充分利用CPU和IO資源，同時(shí)有的線程在做CPU計(jì)算時(shí)，別的線程可以并發(fā)的做IO操作。
GaussDB(for MySQL)使用的并行創(chuàng)建索引，是一個(gè)全鏈路的并行技術(shù)。前面提到，創(chuàng)建索引包含了若干個(gè)階段，我們的并行創(chuàng)建算法，對這里的每個(gè)階段都做并行處理，從讀取數(shù)據(jù)、排序、到創(chuàng)建索引，都是并行操作，每一步都由指定的N個(gè)線程并發(fā)處理。它的邏輯如下圖所示：
GaussDB(for MySQL)尤其對數(shù)據(jù)的歸并排序做了多種優(yōu)化，使得我們常規(guī)的歸并排序能夠充分的并行，充分利用CPU、內(nèi)存和IO的資源。在并行創(chuàng)建索引之后的合并步驟，也使用了一套簡化的算法，正確處理各種索引結(jié)構(gòu)的場景。
GaussDB(for MySQL)的并行創(chuàng)建索引功能，目前支持的索引為Btree二級索引。對于virtual index二級索引，將會在不久的將來提供全面的支持，而MySQL的spatial index和fulltext index不在該并行創(chuàng)建索引覆蓋范圍內(nèi)。
特別要注意的是，主鍵索引的創(chuàng)建目前也是不支持并行的，因此如果一個(gè)并行創(chuàng)建索引的SQL語句包含創(chuàng)建主鍵索引，或者前面提及的spatial index與fulltext index，那么客戶端將會收到一個(gè)告警，提示該操作不支持并行創(chuàng)建索引，同時(shí)該語句會采用單線程創(chuàng)建索引的方式執(zhí)行完成。
從SQL語句的角度，如前所述，創(chuàng)建索引可以采用不同的算法，由于COPY算法（ALGORITHM=COPY）不是采用批量插入的方式，因此不會受益于該并行創(chuàng)建索引優(yōu)化。而對于INPLACE算法，如果創(chuàng)建索引用的是非rebuild的方式，都可以受益于該優(yōu)化；一旦需要使用rebuild的方式創(chuàng)建索引，因?yàn)樯婕暗街麈I索引的建立，將無法使用并行創(chuàng)建索引的算法。
下面我們通過幾個(gè)實(shí)例來了解一下如何使用并行創(chuàng)建索引算法加快創(chuàng)建速度，以及我們的條件約束是如何生效的。
1.我們使用sysbench的表，表內(nèi)有1億條數(shù)據(jù)
2.在該表的k字段建索引，采用社區(qū)默認(rèn)單線程，耗時(shí)146.82s
3.通過設(shè)置innodb_rds_parallel_index_creation_threads= 4啟用4個(gè)線程建索引，可以看到建索引耗時(shí)38.72s，速度提升3.79倍。
4. 假設(shè)我們要修改主鍵索引，雖然指定了多線程，但是會收到一個(gè)warning，實(shí)際上只能通過單線程建索引
首先對innodb_rds_parallel_index_creation_threads這個(gè)參數(shù)進(jìn)行一下說明，它控制了系統(tǒng)中所有并行DDL可以使用的總線程數(shù)，取值范圍是[1-128]。該參數(shù)取值為1表示使用原始的單線程創(chuàng)建索引，取值為N，表示接下來的DDL使用N個(gè)線程創(chuàng)建。如果一個(gè)DDL使用了100個(gè)線程在執(zhí)行，那么另外一個(gè)也要使用并行的DDL且最多只能使用剩下的28個(gè)線程；而如果128個(gè)線程都被并行DDL語句占用了，新來的DDL只能走原始的單線程創(chuàng)建的邏輯。
雖然該并行創(chuàng)建索引加快了索引的創(chuàng)建速度，但是在具體使用場景下，還是需要有審慎的評估。我們知道在并行算法應(yīng)用之后，該DDL對硬件資源的使用會盡可能的充分，這也意味著其它操作就得不到太多的資源了。因此，針對不同的場景需要具體地分析，它決定了我們?nèi)绾蝿?chuàng)建索引。
對于遷移場景，由于這時(shí)候還沒有任何業(yè)務(wù)接入，用戶希望盡快完成所有索引的創(chuàng)建，因此可以盡量設(shè)置多線程數(shù)，比如我們是16核規(guī)格的實(shí)例，那么我們就可以把并行線程的數(shù)量指定為16，加速完成操作。
如果是用戶業(yè)務(wù)運(yùn)行階段要?jiǎng)?chuàng)建索引，我們還是不希望DDL操作，對正在運(yùn)行的業(yè)務(wù)如DML操作等有太多的影響。因此，這時(shí)候創(chuàng)建索引可以指定相對少一些的線程數(shù)量，比如2-4（或者根據(jù)CPU規(guī)格以及負(fù)載決定，同時(shí)不鼓勵(lì)并發(fā)地執(zhí)行多個(gè)DDL操作）。這樣既能相對地加速創(chuàng)建索引的進(jìn)程，也能保證DML的正常進(jìn)行。
綜上所述，GaussDB(for MySQL)支持了并行創(chuàng)建索引，通過縮短創(chuàng)建索引使用的時(shí)間，很好地解決了客戶關(guān)切的兩類問題，提升了客戶的體驗(yàn)。但技術(shù)無止境，在創(chuàng)建索引領(lǐng)域，還有其它的問題需要我們優(yōu)化解決，例如如何減少創(chuàng)建索引步驟對IO的影響等等。我們后續(xù)會針對這些點(diǎn)進(jìn)行優(yōu)化，給客戶帶來更多的驚喜。
目前，華為云GaussDB(for MySQL) 并行創(chuàng)建索引優(yōu)化功能已上線，歡迎大家前往華為云官網(wǎng)體驗(yàn)：云數(shù)據(jù)庫_GaussDB(for MySQL) _分布式云數(shù)據(jù)庫-華為云
附：華為云GaussDB(for MySQL)內(nèi)核專家系列文章
華為海外女科學(xué)家為您揭秘：GaussDB(for MySQL)云棧垂直集成的力量有多大？華為海外女科學(xué)家為您揭秘：GaussDB(for MySQL)云棧垂直集成的力量有多大？-云社區(qū)-華為云
華為云數(shù)據(jù)庫內(nèi)核專家為您揭秘：GaussDB(for MySQL)并行查詢有多快？華為云數(shù)據(jù)庫內(nèi)核專家為您揭秘：GaussDB(for MySQL)并行查詢有多快？-云社區(qū)-華為云
點(diǎn)擊關(guān)注，第一時(shí)間了解華為云新鮮技術(shù)~華為云博客_大數(shù)據(jù)博客_AI博客_云計(jì)算博客_開發(fā)者中心-華為云
*請認(rèn)真填寫需求信息，我們會在24小時(shí)內(nèi)與您取得聯(lián)系。
