整合營銷服務(wù)商

          電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理

          免費(fèi)咨詢熱線:

          MySQL如何優(yōu)雅的執(zhí)行DDL

          MySQL如何優(yōu)雅的執(zhí)行DDL

          、前言

          關(guān)于MySQL DDL表結(jié)構(gòu)變更,各個(gè)工單平臺(tái)基本上都支持了pt-osc及Online DDL的方式,但是,我相信仍然有一大部分人,不太了解這兩種方式各自的優(yōu)缺點(diǎn)是啥,以至于實(shí)際當(dāng)中,會(huì)稀里糊涂的隨機(jī)選一種去執(zhí)行,選對(duì)了固然好,選錯(cuò)了,自然免不了領(lǐng)導(dǎo)的一頓K,這......當(dāng)然是開玩笑的哈。


          在各搜索平臺(tái)上,介紹關(guān)于pt-osc及Online DDL工作原理的文章,不計(jì)其數(shù),但是,對(duì)于非專業(yè)選手而已,又有幾個(gè)人是完全吃透的呢?所以,在這,不打算對(duì)其原理再重復(fù)一遍,僅從他們的執(zhí)行機(jī)制角度出發(fā),介紹各種DDL在選擇不同方式時(shí)所產(chǎn)生的影響,并基于此來分析該如何選擇。


          另,現(xiàn)在普遍使用的版本為5.7,所以,咱就以 MySQL 5.7.24 版本為例。


          二、pt-osc及Online DDL執(zhí)行機(jī)制

          2.1 Online DDL

          ?機(jī)制:MySQL通過Innodb引擎在內(nèi)部執(zhí)行一系列的操作進(jìn)行表變更,當(dāng)然,同一個(gè)表,不同的DDL,會(huì)有不同效果,甚至?xí)霈F(xiàn)一天上一個(gè)地下的差異,所以不同DDL,后面再對(duì)其進(jìn)行具體分析;如果有從庫,則在主庫執(zhí)行完成后,從庫再操作一遍,動(dòng)作和主庫一模一樣(執(zhí)行時(shí)間也很接近)。

          ?優(yōu)點(diǎn):這個(gè)咱后面在講具體SQL時(shí)再進(jìn)行具體分析。

          ?缺點(diǎn):

          ?某些場(chǎng)景下,會(huì)鎖表引發(fā)堵塞增刪改操作,這個(gè)是需要重點(diǎn)注意的,具體場(chǎng)景后面會(huì)標(biāo)紅說明。

          ?如果有從庫,這有一個(gè)很致命的弱點(diǎn):復(fù)制延遲。因?yàn)橹鲙靾?zhí)行的動(dòng)作,會(huì)在從庫再來一遍,如果這個(gè)動(dòng)作是非常耗時(shí)的,那在從庫執(zhí)行(重放主庫的動(dòng)作)的時(shí)間點(diǎn)開始,其后續(xù)所有動(dòng)作都被堵塞住,直到從庫也執(zhí)行完這個(gè)DDL后,才會(huì)繼續(xù)按順序執(zhí)行其他SQL。這就就意味著,從從庫執(zhí)行開始,從庫復(fù)制就出現(xiàn)了延遲,延遲的時(shí)間會(huì)慢慢變大,直到DDL執(zhí)行完后,延遲才會(huì)慢慢變小。

          ?存在數(shù)據(jù)copy的情況時(shí),需要額外的磁盤空間,但有可能同樣的SQL,空間需求會(huì)比使用pt-osc低。

          ?特殊情況:云側(cè)MySQL RDS,本身有一個(gè)隱藏從庫用于高可用,因?yàn)檫@個(gè)隱藏從庫不對(duì)外提供服務(wù),所以基本上業(yè)務(wù)側(cè)也不需要去關(guān)注他。但極端情況,如果大表DDL操作使用Online DDL模式時(shí),在隱藏從庫正在執(zhí)行DDL期間,主庫掛了,那常理就需要切換到隱藏從庫,才能繼續(xù)提供服務(wù),但為了保證數(shù)據(jù)的一致性,隱藏從庫必須要等DDL執(zhí)行完,再回放DDL之后的binlog,然后,才能將其提升為主庫,對(duì)外提供服務(wù),所以這個(gè)恢復(fù)時(shí)間有可能很長(zhǎng)。總得來講,這個(gè)情況對(duì)業(yè)務(wù)而言也是致命的,只不過概率極低。


          2.2 pt-osc

          ?機(jī)制:創(chuàng)建一個(gè)新臨時(shí)表,并在老表上創(chuàng)建3個(gè)觸發(fā)器,再進(jìn)行新老表的數(shù)據(jù)同步,直至新老表數(shù)據(jù)一致后,再進(jìn)行表名互換,達(dá)到表變更的目的。不同的DDL,只要pt-osc支持,他的操作方式都是一樣的,這點(diǎn)與Online DDL完全不同。

          ?優(yōu)點(diǎn):

          ?可以設(shè)置相應(yīng)的參數(shù),根據(jù)主、從庫負(fù)載(比如復(fù)制延遲)的情況,動(dòng)態(tài)調(diào)整數(shù)據(jù)拷貝速度,整個(gè)表結(jié)構(gòu)變更過程相對(duì)比較溫和。

          ?不會(huì)引發(fā)從庫復(fù)制延遲超級(jí)大的情況;

          ?執(zhí)行完后,新表會(huì)將老表占用的碎片空間完全釋放掉。

          ?缺點(diǎn):

          ?需要將老表的所有數(shù)據(jù)都拷貝到新表上,這就意味著拷貝期間,磁盤IO可能較高。

          ?要拷貝全量數(shù)據(jù),所以執(zhí)行時(shí)間也會(huì)很長(zhǎng)。

          ?新臨時(shí)表存放數(shù)據(jù)也需要空間(最大空間需求可能和原表一樣),拷貝數(shù)據(jù)時(shí)還會(huì)產(chǎn)生大量binlog,所以對(duì)于本來空間就緊張的實(shí)例而言,這方式真的是雪上加霜。


          2.3 加鎖

          加鎖情況,想必是大家使用時(shí)關(guān)心較多的一個(gè)問題,但是,我想說,MySQL 5.7加鎖情況會(huì)比你想象中的要好。Online DDL及pt-osc,大部分情況下,只會(huì)在執(zhí)行前后加表元數(shù)據(jù)鎖,其在獲取到表元數(shù)據(jù)鎖并上鎖后,在極短時(shí)間內(nèi)做完后續(xù)相關(guān)動(dòng)作,緊接著就會(huì)將鎖釋放掉。Online DDL除特殊操作外(后面會(huì)說明),大部分情況下,不會(huì)對(duì)現(xiàn)有業(yè)務(wù)造成堵塞影響。在業(yè)務(wù)足夠繁忙時(shí),反而有可能會(huì)出現(xiàn)表結(jié)構(gòu)變更操作獲取不到表元數(shù)據(jù)鎖(鎖等待超時(shí)),從而導(dǎo)致執(zhí)行失敗的情況。


          三、各種DDL操作

          在具體分析后面各種DDL之前,咱統(tǒng)一假設(shè)要操作的表足夠大,要不然表太小的話,不管什么方式都是瞬間完成,就沒有對(duì)比的意義了。另,編寫的DDL語句,如果想用Online DDL方式,咱也不需要刻意去指定 ALGORITHM 及 LOCK 選項(xiàng),就讓MySQL自動(dòng)判斷后默認(rèn)選擇就好。


          下面,咱就從MySQL官方文檔Online DDL對(duì)各種操作的支持角度去分析兩種方式的差異情況。當(dāng)然,如果你的DDL語句同時(shí)含有好幾種不同的操作,那就以最壞的那種情形做參考即可。


          3.1 索引操作

          圖一:Online DDL 索引操作




          3.1.1 創(chuàng)建普通二級(jí)索引

          Online DDL:從圖一,我們可以看出,這會(huì)選擇In Place的方式執(zhí)行,整個(gè)過程,只會(huì)涉及到拷貝二級(jí)索引列相關(guān)的數(shù)據(jù)用于創(chuàng)建索引,所以需要拷貝的數(shù)據(jù),相對(duì)于pt-osc而已,肯定會(huì)少很多,反過來說,執(zhí)行需要的時(shí)間也相對(duì)會(huì)少。如果沒從庫,不存在復(fù)制延遲的問題,那選擇Online DDL顯然會(huì)比pt-osc更優(yōu);但如果有從庫,那復(fù)制延遲的問題,自然是需要考慮的,而且大表復(fù)制延遲的時(shí)間,當(dāng)然也會(huì)較長(zhǎng),如果接受不了延遲,那直接選pt-osc就好。


          pt-osc:復(fù)制整個(gè)表的數(shù)據(jù)用于建新表,優(yōu)勢(shì)是有從庫時(shí),幾乎不存在復(fù)制延遲的問題;劣勢(shì)也很明顯,因?yàn)榭截愓麄€(gè)表的數(shù)據(jù),所以時(shí)間長(zhǎng),同時(shí)磁盤IO也會(huì)變高。


          3.1.2 刪除索引、索引重命名

          Online DDL:從圖一可以看到Only Modifies Metadata對(duì)應(yīng)的是YES,也就意味著僅修改元數(shù)據(jù),速度非常快,幾乎瞬間完成,必選Online DDL。


          pt-osc:直接無視


          3.1.3 變更索引類型、全文索引、空間索引

          咱現(xiàn)在使用的索引類型基本上都是BTREE,幾乎很少用到HASH,同時(shí)也很少見到有用全文索引及空間索引的,所以,這幾種咱就不討論了。


          3.2 唯一索引及主鍵操作

          圖二:Online DDL主鍵操作




          因?yàn)閜t-osc拷貝數(shù)據(jù)的過程,會(huì)依賴于唯一鍵(主鍵或者唯一索引)來校驗(yàn)數(shù)據(jù)的一致性,對(duì)唯一鍵進(jìn)行相關(guān)的操作可能會(huì)引發(fā)各種各樣的問題,所以不管pt-osc實(shí)際支持或不支持這類操作,咱都直接默認(rèn)為不支持就好。也就是涉及主鍵及唯一索引相關(guān)的操作,都直接選Online DDL。但是,需要注意的是,單獨(dú)刪除主鍵的操作,會(huì)引發(fā)鎖表,導(dǎo)致不允許對(duì)表進(jìn)行其他增刪改的操作,也就是增刪改會(huì)被堵塞住,這操作需要慎重考慮。而同一個(gè)DDL里面,刪除老主鍵的同時(shí)又加上新主鍵,是不會(huì)引起堵塞的。


          3.3 列操作

          圖三:Online DDL列操作




          3.3.1 添加列、刪除列、重排列順序、變更列類型、修改列為空或非空

          Online DDL:從圖三可以看出,這6種DDL操作,在選擇Online方式時(shí),都會(huì)重建表,效果上與pt-osc并無太大差別,還得擔(dān)憂從庫復(fù)制延遲的問題,那既然如此,直接選擇pt-osc的方式更省事。


          Online DDL以下這幾種情況會(huì)鎖表,堵塞其他增刪改操作,需要注意:

          1)增加一個(gè)自增列。

          2)單純修改列類型。

          3)修改列名,同時(shí)修改了列類型(該情形應(yīng)該算修改列類型的一個(gè)特殊例子)(只支持 Online DDL)。


          pt-osc:首選。需要注意的是,因?yàn)閜t-osc不支持修改列名,所以上述的第三點(diǎn),只能選擇Online DDL的方式執(zhí)行,但是選擇Online DDL,又會(huì)出現(xiàn)鎖表導(dǎo)致堵塞其他增刪改的操作,所以慎重。


          3.3.2 VARCHAR列增加列大小

          Online DDL:MySQL底層在存儲(chǔ)變長(zhǎng)列VARCHAR列的內(nèi)容時(shí),還會(huì)額外記錄內(nèi)容占用字節(jié)數(shù)的大小,記錄這個(gè)大小,也是需要空間的。另外,還有個(gè)東西咱需要了解下,VARCHAR列存儲(chǔ)一個(gè)字符,使用utf8字符集時(shí),最大需要3字節(jié)(比如存儲(chǔ)一個(gè)中文字符),而utf8mb4最大需要4字節(jié)(比如存儲(chǔ)一個(gè)表情符)。知道了使用什么字符集,咱就可以計(jì)算出存儲(chǔ)一個(gè)VARCHAR變長(zhǎng)列最大需要多少字節(jié)了。


          列存儲(chǔ)最大需要字節(jié)數(shù)=VARCHAR列定義的長(zhǎng)度 * 不同字符集存儲(chǔ)單個(gè)字符需要最大字節(jié)數(shù)


          而記錄列占用字節(jié)數(shù)大小,所需的空間,會(huì)根據(jù) 列存儲(chǔ)最大需要字節(jié)數(shù) 細(xì)分出兩種情況:

          1)列存儲(chǔ)最大需要字節(jié)數(shù)為0-255時(shí),記錄列占用字節(jié)數(shù)大小需要1字節(jié)。

          2)列存儲(chǔ)最大需要字節(jié)數(shù)為256-65535時(shí),記錄列占用字節(jié)數(shù)大小需要2字節(jié)。

          3)因表數(shù)據(jù)行,非大對(duì)象的列,總的存儲(chǔ)內(nèi)容長(zhǎng)度限制就是65535,所以,單列VARCHAR存儲(chǔ)需求自然也不能超過這個(gè)限制,也就是不存在超過65535的情況。


          回歸正題,VARCHAR列增加大小:

          1)如果列長(zhǎng)度增加后,記錄列占用字節(jié)數(shù)大小所需字節(jié)數(shù)不變,也就是列存儲(chǔ)最大需要字節(jié)數(shù)依然在同一個(gè)范圍內(nèi):0-255或256-65535,那這類操作,ALGORITHM支持使用 In Place算法,只會(huì)修改表的元數(shù)據(jù)信息,瞬間完成,此情形,直接選Online DDL即可。

          2)如果列長(zhǎng)度增加后,記錄列占用字節(jié)數(shù)大小所需字節(jié)數(shù)變了,從1字節(jié)變成2字節(jié),ALGORITHM 則只支持COPY算法,這就意味著會(huì)出現(xiàn)數(shù)據(jù)拷貝的情況,同時(shí)會(huì)堵塞其他增刪改的操作,這情形選pt-osc。


          例子:

          # 建表
          create table t1(name varchar(10) null) charset=utf8mb4;
          
          # 列存儲(chǔ)最大需要字節(jié)數(shù)計(jì)算:長(zhǎng)度 10,utf8mb4字符集存儲(chǔ)單字符最大需要字節(jié)數(shù) 4
          # 列存儲(chǔ)最大需要字節(jié)數(shù)=10 * 4=40
          # 記錄列占用字節(jié)數(shù)大小所需空間為1字節(jié)
          
          
          # 表結(jié)構(gòu)變更一
          alter table t1 modify name varchar(63) null;
          
          # 列存儲(chǔ)最大需要字節(jié)數(shù)計(jì)算:長(zhǎng)度 63,utf8mb4字符集存儲(chǔ)單字符最大需要字節(jié)數(shù) 4
          # 列存儲(chǔ)最大需要字節(jié)數(shù)=63 * 4=252
          # 記錄列占用字節(jié)數(shù)大小所需空間依然為1字節(jié),ALGORITHM默認(rèn)選用In Place,Online DDL執(zhí)行瞬間完成
          
          
          # 表結(jié)構(gòu)變更二
          alter table t1 modify name varchar(64) null;
          
          # 列存儲(chǔ)最大需要字節(jié)數(shù)計(jì)算:長(zhǎng)度 64,utf8mb4字符集存儲(chǔ)單字符最大需要字節(jié)數(shù) 4
          # 列存儲(chǔ)最大需要字節(jié)數(shù)=64 * 4=256
          # 記錄列占用字節(jié)數(shù)大小所需空間變?yōu)?字節(jié),ALGORITHM只能使用COPY,引發(fā)數(shù)據(jù)拷貝,堵塞其他增刪改操作,選擇pt-osc
          
          
          


          pt-osc:根據(jù)上述信息選合適的。


          3.3.3 修改列名(只改列名)、設(shè)置/刪除默認(rèn)值、修改ENUM/SET列定義

          Online DDL:從圖三可以看出,這類操作會(huì)只修改表元數(shù)據(jù)信息,速度極快,直接選Online DDL方式即可


          pt-osc:直接無視


          3.3.4 修改自增列的自增值

          Online DDL:在MySQL 8.0版本前,自增值不存在持久化的概念,修改這個(gè)值,只會(huì)在內(nèi)存中修改,更不涉及數(shù)據(jù)的拷貝及變動(dòng),所以直接使用Online DDL方式即可。


          pt-osc:直接無視


          3.4 Generated列操作

          圖四:Online DDL 虛擬列操作




          3.4.1 新增/刪除Generated虛擬列

          Online DDL:虛擬列不涉及數(shù)據(jù)存儲(chǔ)的問題,所以新增和刪除都只會(huì)涉及到表元數(shù)據(jù)的變更,幾乎瞬間完成,直接選用Online DDL方式執(zhí)行即可。


          pt-osc:直接無視


          3.4.2 新增/修改/刪除Generated存儲(chǔ)列、修改Generated虛擬列順序

          Online DDL:這幾種操作,在選擇Online DDL時(shí),都會(huì)涉及到表重建的問題,大表執(zhí)行時(shí)間不會(huì)短,另外,新增/修改Generated存儲(chǔ)列 以及 修改Generated虛擬列順序,都會(huì)鎖表,引發(fā)堵塞其他增刪改操作,所以,建議選pt-osc。


          pt-osc:首選


          3.5 外鍵操作

          圖五:Online DDL外鍵操作




          如果表存在外鍵依賴,后期對(duì)父表進(jìn)行各種DDL操作時(shí),數(shù)據(jù)庫會(huì)有較大的風(fēng)險(xiǎn),嚴(yán)重的甚至?xí)i表,所以不建議用外鍵。


          3.6 表操作

          圖六:Online DDL表操作




          3.6.1 修改表名

          Online DDL:從圖六看出,Online DDL修改表名,只會(huì)涉及到修改表的元數(shù)據(jù)信息,瞬間完成。


          pt-osc:不支持


          3.6.2 表碎片整理、更改行格式、修改字符集、收集統(tǒng)計(jì)信息

          Online DDL:咱對(duì)表的操作,常用到的,可能就是表碎片整理、更改行格式(比如改成壓縮模式),修改字符集(含內(nèi)容轉(zhuǎn)換)以及收集統(tǒng)計(jì)信息,這些操作,從圖六也看到了,基本都是需要重建表,建議首選pt-osc。


          pt-osc:首選


          3.6.3 其他相關(guān)的表操作

          其他操作平常基本很少用到,暫時(shí)不討論。


          3.7 表空間操作

          圖七:Online DDL表空間操作




          在實(shí)際使用中,幾乎見不到,咱就不討論了。


          3.8 表分區(qū)操作

          圖八:Online DDL表分區(qū)操作




          表分區(qū)相關(guān)的操作較多,咱就挑比較常用的進(jìn)行分析,其他操作不做贅述。


          3.8.1 普通表轉(zhuǎn)分區(qū)表

          Online DDL:他的本質(zhì)是新建一個(gè)臨時(shí)表,每個(gè)分區(qū)對(duì)應(yīng)一個(gè)數(shù)據(jù)文件,然后進(jìn)行拷貝,拷貝完畢后,表名互換,刪除老表。眼熟不?從某種程度上講,這個(gè)過程與pt-osc是相似的,但是,Online DDL方式會(huì)鎖表,堵塞其他增刪改操作,所以,直接選擇pt-osc方式即可。


          pt-osc:必選


          3.8.2 新增分區(qū)、刪除分區(qū)、TRUNCATE分區(qū)

          Online DDL:

          新增分區(qū),只分析常用的RANGE及LIST分區(qū)。RANGE分區(qū)新增分區(qū),有個(gè)嚴(yán)格的限制,新分區(qū)less than的值必須是遞增的,換句話講就是不存在數(shù)據(jù)拷貝的問題。LIST分區(qū),這個(gè)更直接,相關(guān)內(nèi)容如果在LIST分區(qū)中不存在,直接不允許插入,新增分區(qū)也不存在數(shù)據(jù)拷貝的問題。所以,這兩種選用Online DDL時(shí),操作幾乎都是瞬時(shí)完成的,直接使用Online DDL即可。


          刪除分區(qū)時(shí),會(huì)對(duì)當(dāng)前分區(qū)上鎖,堵塞該分區(qū)的其他增刪改操作,但既然你都打算刪除分區(qū)了,想必自然也不會(huì)再對(duì)該分區(qū)有其他操作。 其對(duì)應(yīng)系統(tǒng)底層的操作,類似于直接將分區(qū)對(duì)應(yīng)的物理文件進(jìn)行刪除,操作時(shí),如果文件足夠大,系統(tǒng)IO會(huì)瞬間暴漲,繼而影響業(yè)務(wù),所以建議在業(yè)務(wù)低峰期間進(jìn)行。


          TRUNCATE分區(qū)操作,對(duì)應(yīng)系統(tǒng)底層的操作,類似于直接將分區(qū)對(duì)應(yīng)的物理文件進(jìn)行清空,操作時(shí),如果文件足夠大,系統(tǒng)IO會(huì)瞬間暴漲,繼而影響業(yè)務(wù),所以建議在業(yè)務(wù)低峰期間進(jìn)行。


          pt-osc:直接無視


          四、結(jié)束語

          從上面的介紹可以看出,DDL相關(guān)的操作較多,想要完全記住各種操作選那種方式最合適,想必也是件費(fèi)神的事情。如果上面信息對(duì)你有用,點(diǎn)贊收藏起來,用到時(shí)再慢慢參考即可。



          參考:

          ?https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-column-operations?

          者按:這個(gè)世界上唯一不變的東西只有變化本身。無論是既有者還是顛覆者對(duì)變化都很重視。從既有者的角度來說,弄清楚某件事情究竟是平臺(tái)轉(zhuǎn)移還是系統(tǒng)噪聲非常關(guān)鍵。因?yàn)槿绻瞧脚_(tái)轉(zhuǎn)移的話,自己就需要未雨綢繆;如果是系統(tǒng)噪聲,那就不需要浪費(fèi)太多的資源去應(yīng)對(duì)。從顛覆者的角度來說,除了弄清楚變化的本質(zhì)以外,知道顛覆會(huì)采取什么樣的路徑至關(guān)重要。因?yàn)楹芏鄤?chuàng)意的前景總是非常美好的,但道路卻是非常曲折的。當(dāng)我們對(duì)AI、區(qū)塊鏈之類的新興技術(shù)做出判斷時(shí),最好是從過去技術(shù)發(fā)展史汲取經(jīng)驗(yàn)。曾領(lǐng)導(dǎo)開發(fā)了Office 95、97并擔(dān)任過微軟Windows事業(yè)部總裁的Steven Sinofsky回顧了Office一路上曾經(jīng)遭遇的各種挑戰(zhàn)以及生死抉擇,是一個(gè)很好的案例參考。

          《星際迷航:可汗怒吼》中小林丸的屏幕上詳細(xì)列出了Savik面臨的一種“無法取勝”的競(jìng)爭(zhēng)局面。

          這是個(gè)玩具。它是下一個(gè)大事物。技術(shù)很神奇。但技術(shù)也是很瑣細(xì)的。在討論“區(qū)塊鏈”時(shí)爭(zhēng)論很容易陷入到抽象之中。

          可是如果你正處在一場(chǎng)技術(shù)轉(zhuǎn)變/顛覆之中呢?

          這是一個(gè)有關(guān)微軟Office的故事。

          似乎每個(gè)人對(duì)區(qū)塊鏈都有自己鮮明的觀點(diǎn),基于跟過去的任何形式的類比。如果有人提出區(qū)塊鏈?zhǔn)歉ヂ?lián)網(wǎng)本身一樣大的東西的話,按照很多人的說法,這個(gè)人既不懂區(qū)塊鏈,也不懂互聯(lián)網(wǎng)。

          在這里我想分享一個(gè)已經(jīng)持續(xù)進(jìn)行了25年的故事,一場(chǎng)有可能對(duì)微軟Office造成“威脅”的平臺(tái)轉(zhuǎn)移,我的目的是希望你從中可以為像區(qū)塊鏈這樣的技術(shù)在平臺(tái)轉(zhuǎn)移中如何發(fā)展,以及實(shí)際的顛覆會(huì)呈現(xiàn)出一種非常不同的“形態(tài)”提出充分的理由。

          這是因?yàn)樵诩扔惺袌?chǎng)里,尤其是大型的既有市場(chǎng)里,“下一個(gè)大事物”從來都不是用新技術(shù)建造的舊事物的新版本。你必須考慮所有的碟子在空中是怎么旋轉(zhuǎn)的,必須假定一切都有可能發(fā)生改變。

          到2000年時(shí)Office已經(jīng)連續(xù)經(jīng)歷了長(zhǎng)達(dá)8年的爆發(fā)式增長(zhǎng),那年的收入已經(jīng)達(dá)到了100億美元。產(chǎn)品從個(gè)人購買“轉(zhuǎn)型”到企業(yè)購買和IT部署。看起來它的情況安全極了。

          現(xiàn)在可能很多人都不記得了但微軟Office其實(shí)是一款消費(fèi)者產(chǎn)品。整個(gè)GTM都是跟零售、大規(guī)模市場(chǎng)和個(gè)人有關(guān),軟件市場(chǎng)就是這樣的。在1990年代中后期,Office(以及Windows NT和Exchange)進(jìn)行了一次所謂的大規(guī)模轉(zhuǎn)型,朝著企業(yè)端發(fā)展,并且建立了一個(gè)可管理的賬戶銷售模型。

          上一代的競(jìng)爭(zhēng)(Lotus/IBM、Borland、WordPerfect)依然“存在”。新的競(jìng)爭(zhēng)也來了,也就是開源版的所謂的“開放”O(jiān)ffice。我們對(duì)自己的執(zhí)行能力有信心,認(rèn)為次要/免費(fèi)產(chǎn)品并不會(huì)對(duì)我明構(gòu)成實(shí)質(zhì)威脅。

          Office作為個(gè)人應(yīng)用已經(jīng)發(fā)展成羽翼豐滿,每一個(gè)都承擔(dān)了某一類別的細(xì)分功能或者“直面”了不同的競(jìng)爭(zhēng)對(duì)手。在套件的戰(zhàn)爭(zhēng)中,沒有一個(gè)主要競(jìng)爭(zhēng)對(duì)手具備完全的有競(jìng)爭(zhēng)力的套件(文字處理器、電子表格、圖形、數(shù)據(jù)庫,然后是電子郵件)。鑒于這一歷史,團(tuán)隊(duì)普遍的看法是,直接跟我們沖突的競(jìng)爭(zhēng)對(duì)手或者甚至開源項(xiàng)目對(duì)我們構(gòu)成的競(jìng)爭(zhēng)威脅都很小。盡管如此,我們還是非常注意OpenOffice,因?yàn)樗麄兛偸浅覀儭N矣浀糜幸淮卧谫Q(mào)易展上我在一個(gè)攤位看到了一個(gè)演示,我注意到他們的“PowerPoint”菜單跟Office不一樣(還有他們的Excel和Word也是)。當(dāng)我向他們指出這一點(diǎn)時(shí)他們感到很震驚,承諾當(dāng)天下午會(huì)“修復(fù)”這個(gè)問題。我因此反而沒那么擔(dān)憂了,因?yàn)樗麄兊南敕ㄊ强寺ffice。

          不過它們?nèi)匀涣糇∈袌?chǎng)上。這里面真正有新意的是這是兩種不同的技術(shù)路線的首次競(jìng)爭(zhēng)。

          (1)用Java編寫的Office(同時(shí)也是可能的開源,以及WORE——一次編寫隨處運(yùn)行的首次亮相)

          (2)給瀏覽器使用的Office

          試著不要用事后諸葛亮的角度去思考該怎么做。

          當(dāng)你已經(jīng)知道了結(jié)果之后是很難從過去的角度去吸取這些經(jīng)驗(yàn)教訓(xùn)的。這對(duì)于商學(xué)院的學(xué)員組隊(duì)想從案例研究中學(xué)到東西來說是個(gè)挑戰(zhàn)。但這個(gè)案例方法不是跟特定技術(shù)的事實(shí)有關(guān),重點(diǎn)是要知道經(jīng)理和領(lǐng)導(dǎo)如何去決定該怎么辦。所以我們這里討論的焦點(diǎn)也會(huì)放在這上面。

          說到商學(xué)院,當(dāng)時(shí)我正在休假去哈佛商學(xué)院教書。學(xué)生的直接反映差不多是“Office已死”。這令人震驚。我不斷地問為什么我還在微軟工作。

          此外談到商學(xué)院那段時(shí)間,1998年我正在休假時(shí)正值“創(chuàng)新者的窘境”剛剛冒出來,GBS的走廊里個(gè)個(gè)都在討論顛覆。這就是為什么學(xué)生和所有的老師都非常確信Office有可能成為第一個(gè)也是最大一個(gè)顛覆的犧牲品。因?yàn)楦鶦lay(Clay Christensen,創(chuàng)新者的窘境的提出者)只有幾門之隔,所以那是個(gè)非常令人興奮的學(xué)期,雖然經(jīng)常要為微軟辯護(hù)。

          Java Office與其說是一個(gè)產(chǎn)品不如說是一場(chǎng)運(yùn)動(dòng)。很多“applet”(Office是應(yīng)用,applet是按需的精益的小應(yīng)用)都要“取代”O(jiān)ffice。組件化已經(jīng)成為運(yùn)動(dòng)。微軟內(nèi)部很多人都認(rèn)為組件架構(gòu)是未來,尤其對(duì)于企業(yè)應(yīng)用來說。

          復(fù)合工作流與應(yīng)用,以及用小規(guī)模的代碼(跨任何OS)提供的技術(shù)吸引力/狂熱非常之高,因?yàn)镺ffice是一個(gè)龐大的單一程序,是“膨脹軟件”。光是運(yùn)行SETUP就已經(jīng)夠痛苦的了。

          但是我們?cè)?jīng)試過用“OLE”開發(fā)組件,也試過“編輯由不同部分組成的文檔”的辦法,結(jié)果完全是個(gè)失敗。神奇的彈出菜單,在小矩形框內(nèi)編輯……

          這整個(gè)“組件”運(yùn)動(dòng)基本上是技術(shù)優(yōu)先的思路。它幾乎是“面向?qū)ο蟆钡漠a(chǎn)物,我在職業(yè)生涯的前5年基本上都在“處理”C++(當(dāng)時(shí)對(duì)世界來說是個(gè)新東西)。認(rèn)為Office的膨脹和管理困難可以用組件“治愈”的IT專業(yè)人士太多了……因?yàn)閺亩x來看組件就應(yīng)該是更容易或者類似的。

          重要的是要認(rèn)識(shí)到IT世界對(duì)微軟還不習(xí)慣,而當(dāng)時(shí)發(fā)生的大事是要“減少總擁有成本”——這個(gè)基本上由于Windows+Office導(dǎo)致的,當(dāng)時(shí)IT界的觀念是應(yīng)該制訂解決方案。認(rèn)為基于可重用組件開發(fā)的解決方案可以促進(jìn)更快速更靈活的應(yīng)用。

          于是組件雙管齊下對(duì)現(xiàn)狀形成了沖擊。同時(shí)Java正好又是很新很酷的面向?qū)ο缶幊陶Z言。盡管很多人已經(jīng)意識(shí)到面向?qū)ο蟪朔炊侠哿怂俣炔⑶乙肓司幊虖?fù)雜性以外其實(shí)對(duì)現(xiàn)狀并沒有什么改變,但這一點(diǎn)也無關(guān)緊要。

          這是Word文檔內(nèi)部一個(gè)Excel組件的截屏。其基本想法是這樣你就不需要在應(yīng)用/窗口之間來回切換了因此你的目標(biāo)就是一份很好的打印文檔。只需要點(diǎn)擊菜單和工具欄就會(huì)切換到“Excel”然后你就可以編輯電子表格之類的東西了。

          那如果下次別人也發(fā)現(xiàn)了這種做法之后我們是不是應(yīng)該對(duì)他們有可能摧毀我們感到害怕呢?或者這是不是一切的未來的又一個(gè)失敗的信號(hào)呢?

          這里面的風(fēng)險(xiǎn)相當(dāng)高!

          像上面例子中的組件完全就是個(gè)失敗。他們強(qiáng)調(diào)PC非常脆弱,而且對(duì)于最終用戶來說一般非常笨重。他們給一個(gè)“套件”做了一個(gè)非常棒的演示,但就僅此而已了。此外它們開發(fā)和測(cè)試也非常復(fù)雜,這令仍然專注于遺留競(jìng)爭(zhēng)對(duì)手的團(tuán)隊(duì)感到極其沮喪。

          順便說一句,這些Java Applet對(duì)資源的占用通常是Office的10倍,但是能力卻不及后者的1/100。這樣的東西是很難行得通的。這些東西想要成為可靠的替代品或者威脅是非常困難的。

          我的天吶這些Java小應(yīng)用太可怕了。Java很慢,占內(nèi)存又非常多,而且根本就是很詭異。Office就有很豐富的歷史,尤其是第一個(gè)Windows應(yīng)用使用解釋型語言(類似C)編寫的,團(tuán)隊(duì)后來花了好幾個(gè)產(chǎn)品周期才把解釋型語言干掉了。現(xiàn)在Java又跳出來告訴全世界“不,這才是正道。”在我們看來這就是胡扯。@jondevaan的態(tài)度尤其鮮明,因?yàn)樗诮馕銎魃厦婊ㄙM(fèi)的時(shí)間實(shí)在是太多了,他一直都想讓Excel跑快一點(diǎn)。對(duì)我個(gè)人來說,Hava也是垃圾回收這一事實(shí)也提供了這是胡扯的充分證據(jù),因?yàn)樗撕芏嗄陼r(shí)間攻擊說C++并沒有真正的垃圾回收機(jī)制,而真正的面向?qū)ο蟪绦騿T時(shí)使用垃圾回收的。

          因此你可以看到跟當(dāng)時(shí)WWW和現(xiàn)在的區(qū)塊鏈的一些類比,這些新的解決方案在執(zhí)行那些你知道如何做快的事情上往往執(zhí)行得非常糟糕。WWW渲染文檔格式很慢,這也難怪,因?yàn)檫@種使用ASCII碼的協(xié)議跟文檔格式并沒有太大關(guān)系。

          但這卻幾乎不能阻止IT、開發(fā)者、內(nèi)部陣營(.net!)的人不斷地主張組件以及用這種新方式重寫Office才是未來。跟這種聲音做斗爭(zhēng)的壓力很大。

          記住,這個(gè)我們之前已經(jīng)試過了,所以顯然我們必須早點(diǎn)行動(dòng)!

          極力鼓吹Office應(yīng)該重寫的戰(zhàn)略思想家和業(yè)界權(quán)威的數(shù)量之多再怎么夸張都不為過。顯然Office已經(jīng)完蛋了,而他們已經(jīng)看到了未來。

          但是組件、解釋器以及垃圾收集就像是三重彩投注一樣,從這么一個(gè)地方開始作為起點(diǎn)簡(jiǎn)直是瘋了。

          與此同時(shí),Exchange郵件團(tuán)隊(duì)引領(lǐng)了DHTML/AJAX/XMLHttpRequest的潮流,并且將基于瀏覽器的電子郵件帶上了一個(gè)新的臺(tái)階(用來用于gmail、google map上),這開辟了重塑Office的又一個(gè)前沿,針對(duì)的主要是Outlook。(注意基本/高級(jí)模式——這在DTTML中是可選的)

          然后就冒出了Internet Explorer、Dynamic HTML (DHTML)再加上XMLHttpRequest。這似乎就像魔法一樣。它還有一個(gè)額外好處就是當(dāng)時(shí)它只有在IE瀏覽器上才能行,IE團(tuán)隊(duì)自然喜歡這一點(diǎn)。

          這完全是另一種競(jìng)爭(zhēng)性挑戰(zhàn),也是針對(duì)Office的一種架構(gòu)方案。

          所以可以想象這又要連續(xù)開很多會(huì)來進(jìn)行討論。對(duì)于微軟的觀察者來說,.net的人焦點(diǎn)都放在Java而IE的人則關(guān)注HTML,兩方都希望Office在這些新平臺(tái)上重寫。你可以想象我要出席所有那些會(huì)議。

          在互聯(lián)網(wǎng)時(shí)代,Outlook是Office新的靠山,所以這里面的風(fēng)險(xiǎn)很大。

          但再次地這要面對(duì)距離它很遙遠(yuǎn)的功能子集問題,而Outlook的歷史才有3年時(shí)間!

          盡管這次是一支團(tuán)隊(duì)與另一支團(tuán)隊(duì)之爭(zhēng)。不是組織之間,而是技術(shù)策略/架構(gòu)之爭(zhēng)。

          Outlook是全新產(chǎn)品。這東西還幾乎用不了。97年時(shí)對(duì)它的評(píng)測(cè)頂多算是不慍不火(請(qǐng)不要讓我Google Walt Mossberg的評(píng)測(cè)!)。Outlook 98迅速增加了互聯(lián)網(wǎng)協(xié)議,因此引入了困擾微軟客戶端長(zhǎng)達(dá)10年的雙產(chǎn)品分裂。然后Outlook 2000又帶來了2種“模式”等等。換句話說,為了讓*Windows*電子郵件能用就夠我們忙的了。

          但然后引領(lǐng)/發(fā)明了AJAX的Exchange團(tuán)隊(duì)開發(fā)出了完美的API來解決Outlook在Windows上面遇到的問題,做法就是向Exchange服務(wù)器發(fā)送請(qǐng)求并且顯示很多行的電子郵件。這讓Outlook看起來很慢!與此同時(shí)Outlook已經(jīng)在客戶端實(shí)現(xiàn)了一堆的功能,所以客戶端/web就很不對(duì)稱,這正是客戶所不想看到的。可以證明為什么開發(fā)電子郵件的架構(gòu)是錯(cuò)誤的材料還有很多。

          在外部有很多人都在用Ajax開發(fā)基于瀏覽器的創(chuàng)作工具。

          這很令I(lǐng)E團(tuán)隊(duì)感到沮喪,因?yàn)镺ffice團(tuán)隊(duì)不做AJAX Office應(yīng)用。所以自然地IE團(tuán)隊(duì)總是非常踴躍地宣傳我們的各種“競(jìng)爭(zhēng)對(duì)手”。平臺(tái)就是這樣的!

          OWA(outlook web access,無需客戶端直接通過互聯(lián)網(wǎng)讀取發(fā)送郵件)對(duì)于輕量電子郵件很好但不適合支持主流的電子郵件和日歷功能。這也是一個(gè)很好的IE展示。于是Yahoo、Hotmail、AOL等開始大力宣傳使用DHTML,很多很酷的演示開始出現(xiàn),其中就包括開發(fā)類似Office之類的東西。PowerPoint(或者畫圖)尤其是個(gè)目標(biāo)。

          Office支持作為文件格式的HTML,但不支持作為編輯運(yùn)行時(shí)。協(xié)作服務(wù)器跟Office配合有大量的工作要做。比方說參見edition.cnn.com/TECH/computing……

          Office正面臨3種競(jìng)爭(zhēng)性顛覆:

          免費(fèi)版

          客戶端Java版

          瀏覽器/HTML版

          每一種的實(shí)質(zhì)是:

          a)下一場(chǎng)重大平臺(tái)轉(zhuǎn)移

          b)完全是個(gè)錯(cuò)誤的想法

          c)可能是正確的想法,但是當(dāng)時(shí)實(shí)現(xiàn)還為時(shí)尚早

          與此同時(shí)我們是個(gè)體量達(dá)100億美元的業(yè)務(wù)。

          圍繞著Java和AJAX的初創(chuàng)企業(yè)開始像雨后春筍一樣冒出來。大多數(shù)都是采取直接山寨Office的方式。當(dāng)然,這是我們的看法(偏見)所以風(fēng)險(xiǎn)不大。

          整個(gè)公司對(duì)Office業(yè)務(wù)都感到非常擔(dān)心。提供了很多“幫助”。大公司就是這么運(yùn)作的。

          想象一下,你正在致力于一項(xiàng)10年間從10億美元做到了100億美元并且在每一個(gè)細(xì)分領(lǐng)域把10多個(gè)競(jìng)爭(zhēng)對(duì)手都痛煸了一頓還贏下了Mac和Windows(以及OS/2)兩個(gè)市場(chǎng)的業(yè)務(wù)。現(xiàn)在互聯(lián)網(wǎng)似乎突然之間就冒了出來同時(shí)你還面臨著Java的架構(gòu)性競(jìng)爭(zhēng)以及開源的結(jié)構(gòu)性競(jìng)爭(zhēng)。而且它們?nèi)贾苯用闇?zhǔn)了你的薄弱點(diǎn),擁有成本、復(fù)雜性以及膨脹。壓力可想而知。

          我不斷地列舉用那些技術(shù)做“Office”的所有新產(chǎn)品。任何時(shí)候我們的規(guī)劃文檔里面都會(huì)有各種大表,我們的產(chǎn)品規(guī)劃總是在同時(shí)研究著十多種競(jìng)品。似乎每一次貿(mào)易展(我們當(dāng)時(shí)還是通過這種渠道去了解)都報(bào)道又有新的基于瀏覽器或者Java的Office出來了。

          與此同時(shí),內(nèi)部來自技術(shù)專家要求作出回應(yīng)的呼聲非常高。銷售人員一個(gè)都不想要除非時(shí)他們正在銷售但去掉了他們反對(duì)的(膨脹、TCO)東西。

          絕對(duì)是Office最困難的時(shí)候:我們已經(jīng)成為守江山的人了,現(xiàn)在要面對(duì)無數(shù)新的/潛在的風(fēng)險(xiǎn)了。

          但是所有這些都沒有用在任何“真正”的東西上,除了Outlook。Google Maps/Gmail還要幾年后才出來呢。

          Oracle還折騰“網(wǎng)絡(luò)計(jì)算機(jī)”的概念。Office病毒/惡意軟件破壞了品質(zhì)。膨脹軟件。WWW機(jī)會(huì)巨大。

          到處都是下一個(gè)基本架構(gòu)。

          你能想象Office看起來有多脆弱呢?

          機(jī)構(gòu)對(duì)今天的區(qū)塊鏈又會(huì)怎么看呢?

          與此同時(shí),那些新東西沒有一個(gè)能行的。我的意思是說它們真的都不能工作。且不說OpenOffice抱怨的那些大問題(文件格式兼容性),就連基本的編輯功能都是超級(jí)笨重。性能很糟糕。此外大多數(shù)人的連接都不好,而每一個(gè)以瀏覽器為中心的在線工具都要解決離線使用的問題。這些所謂的顛覆根本顛覆不了。

          只是每一位權(quán)威和客戶都關(guān)注未來,要求給出答案。

          賭注:我們已經(jīng)在服務(wù)器端協(xié)作投入很大的賭注(SharePoint)。

          需要對(duì)Office的核心價(jià)值賭一把。悄然開始我們自己的HTML客戶端——Office“伴侶”。

          想法很簡(jiǎn)單:如果有東西正在替代Office的話我們就自己做。

          我們的答案是聚焦于我們相信自己能做成的東西。

          我們已經(jīng)開始在HTML身上下注了,那就是很早就在Word和PowerPoint支持它作為一種渲染格式(編輯是后面的事)。冷知識(shí):Word的Internet Assistant for HTML比Netscape 1.0的出來的時(shí)間還早。將幻燈片保存為帶有導(dǎo)航按鈕的一系列的JPEG是早期DIY和企業(yè)網(wǎng)站的標(biāo)志。PowerPoint很早就開發(fā)了這一插件而且特別流行。

          1998年我們已經(jīng)收購了Vermeer FrontPage,并且非常努力想要把Office文檔的“l(fā)ive web”概念推廣到工作場(chǎng)所。這個(gè)的第一次迭代是所謂的“Office Web Server(OWS)”后來演變成為了泛化的FrontPage。OWS屬于Sharepoint的“團(tuán)隊(duì)網(wǎng)站部分”或者我喜歡把它叫做“放文件的地方”。

          但新的大賭是開發(fā)web版的Word、Excel和PowerPoint——運(yùn)行在瀏覽器上面并且使能在OWS/SharePoint內(nèi)編輯真正Office文檔的原生HTML應(yīng)用。我們知道我們不可能把所有的Office功能都做出來,因?yàn)槲覀円呀?jīng)看到每個(gè)人都失敗了而且我們還得兼顧現(xiàn)有的業(yè)務(wù)。

          這是超級(jí)困難的,因?yàn)榇蠖鄶?shù)HTML應(yīng)用都是“免費(fèi)”的,所以甚至做這些否被認(rèn)為是有風(fēng)險(xiǎn)的。這個(gè)是“免費(fèi)版的Office”嗎?銷售根本就不想要這樣的東西!

          但從產(chǎn)品的角度來說,這是值得投資的而且時(shí)機(jī)合適。但這還不夠。

          營銷和銷售隊(duì)伍可以說非常害怕“web版的Office”。他們好不容易才在跟這些新流行的競(jìng)爭(zhēng)對(duì)手的戰(zhàn)爭(zhēng)中“贏下”了客戶,所以這幫人最不愿意做的一件事就是回過頭來調(diào)整原先簽訂的交易(這些交易是持續(xù)多年企業(yè)協(xié)議的開始,今天我們稱之為SaaS,但當(dāng)時(shí)的說法叫“維保”)。他們的假設(shè)是如果微軟做web版Office的話那應(yīng)該是免費(fèi)的。其價(jià)格應(yīng)該要比“完全”版的桌面Ofice低,原因是它能做的事情變少了(你懂的,因?yàn)閮r(jià)格是按照代碼行數(shù)計(jì)算的)。

          Gmail出來了。Google收購了Writely,2web。并把這些工具植入到gmail1里面。基本上把Office文檔從Google webmail流里面擠掉了。花了6年多的時(shí)間才看到這一場(chǎng)景實(shí)現(xiàn)。

          Office的銷售仍然不受此任何影響。

          然后gmail出來了,后續(xù)又集成了后來成為Google App的應(yīng)用服務(wù)的早期版本。當(dāng)時(shí)已經(jīng)進(jìn)入到2006年了。

          記住,Google Appl還處在beta階段,直到2009年末才正式推出,直接產(chǎn)生收入更是八字沒一撇,直到現(xiàn)在針對(duì)企業(yè)進(jìn)行大力營銷之后才成為現(xiàn)實(shí)。

          有人可能在猜那段時(shí)間我們有沒有進(jìn)行過任何自己做還是收購別人的決策……當(dāng)然我們?cè)诓粩嗵岢鲞@些想法。但從收購的角度來說這些這些潛在收購對(duì)象沒有一個(gè)能行的,而且說實(shí)話技術(shù)圓鋸也排除了這一點(diǎn)可能性。當(dāng)Google收購web工具時(shí)我們的態(tài)度是困惑多過擔(dān)心,但我們也知道他們的CEO長(zhǎng)期以來的商業(yè)策略就是做點(diǎn)事情(Open Offuce!)來干擾并且/或者阻止微軟。所以我們很警覺。而且事實(shí)上市面上可以集成進(jìn)Office Web Sever的Java版或者web版工具都已經(jīng)被收購?fù)炅恕K詫?duì)既有者來說這是典型的集成挑戰(zhàn)。

          下一步是把Office Web App的流程植入到基于瀏覽器的郵件里面。

          但是客戶那邊仍然非常關(guān)心在功能上能跟原有Office“平起平坐”,此外他們也很在意經(jīng)濟(jì)性(定價(jià))。

          在平臺(tái)轉(zhuǎn)移的時(shí)候,產(chǎn)品需要發(fā)展哪怕企業(yè)不能發(fā)展/或者不想發(fā)展。

          我們很多人已經(jīng)從類似IE和Office這樣的地方轉(zhuǎn)移出去并且現(xiàn)在占據(jù)了Windows(以及“Windows Live”)領(lǐng)地工作的地方。所以自然地我們?cè)缙谧龅囊患虑槭菍ffice Web App連接上Hotmail和OneDrive(Skydrive),以此來與gmail競(jìng)爭(zhēng)(當(dāng)時(shí)Hotmail正在與龐大/免費(fèi)的郵箱做斗爭(zhēng))。

          對(duì)免費(fèi)Office的恐懼很強(qiáng)烈。即便web app的存在也被視為有可能對(duì)Office的定價(jià)形成不好的壓力。顯然產(chǎn)品團(tuán)隊(duì)沒有經(jīng)過銷售與營銷挑戰(zhàn)是普遍認(rèn)識(shí)。

          今天的Office大概是350億美元的業(yè)務(wù)。Google Docs很大但是甚至連它的10%都不到。Office Web App很棒但絕大部分人的生產(chǎn)力工具仍然以桌面Office為主。

          從中可以得到哪些經(jīng)驗(yàn)教訓(xùn)呢?相當(dāng)微妙。很容易可以看出這是雙向的。

          這段時(shí)間我們還對(duì)Office下了另一個(gè)賭注,“托管Exchange”。這是完全是故事的另外一支了,但是故事的脈絡(luò)跟這個(gè)十分類似,也是“必須要”與“不能要”以及“沒法用”之間的決策。

          不管是有意為之還是出于競(jìng)爭(zhēng)的必要性因?yàn)橹苯訉?duì)抗是沒有用的,Google Docs(現(xiàn)在的G-Suite)已經(jīng)走上了一條不同的發(fā)展方向。專注于實(shí)時(shí)協(xié)作,淡化跟Office的直接競(jìng)爭(zhēng),并且開發(fā)不同的功能加上大規(guī)模的免費(fèi)“分發(fā)”,這吸引了大量的受眾。不過賺的錢就不是很多了。Google并沒有報(bào)告G-Suite的收入情況但這是Google 40億美元左右其他業(yè)務(wù)板塊的一部分,里面也許包含了Cloud、硬件等。我這里是猜的。

          平臺(tái)轉(zhuǎn)移已經(jīng)發(fā)生。這不是Office克隆、基于Java的克隆或者基于瀏覽器的克隆。

          它的發(fā)展軌跡跟朝著移動(dòng)、app、聊天應(yīng)用以及實(shí)時(shí)協(xié)作轉(zhuǎn)移的走勢(shì)不一樣。

          工作的本質(zhì)正在改變,工具也在引領(lǐng)和跟隨。

          最終平臺(tái)轉(zhuǎn)移并沒有來自Java或者甚至基于瀏覽器的編輯/創(chuàng)作工具(也不來自DHTML/Ajax)。顛覆之所以發(fā)生是因?yàn)楹芏嗷顒?dòng)件。

          尤其是移動(dòng)形態(tài)因子以及聊天app的崛起改變了生產(chǎn)力實(shí)質(zhì)的版圖。現(xiàn)在正在發(fā)生但一直都在持續(xù)進(jìn)行中。

          這里有一篇文章是我寫的,里面談到了工作本質(zhì)的變化——持續(xù)生產(chǎn)力:在新時(shí)代工作的新工具和新手段。

          關(guān)鍵跟這個(gè)話題的始作俑者有關(guān),區(qū)塊鏈,這種顛覆發(fā)生在另外一個(gè)跟傳統(tǒng)智慧描述不同的抽象層面。它發(fā)生在更高的“app”層面而不是純粹的技術(shù)層面。這是因?yàn)樾乱淮墓ぞ咧圃煺叩某霈F(xiàn)以及技術(shù)棧和基于此的應(yīng)用的出現(xiàn),但是并沒有把技術(shù)棧視為差異化的因素。關(guān)鍵在于技術(shù)棧能做什么。

          當(dāng)重大轉(zhuǎn)變發(fā)生時(shí),一切都會(huì)變化,不僅僅只是技術(shù)。

          WWW并不僅僅只是改變了客戶端/服務(wù)器使用的協(xié)議,或者文檔的格式。“一切”都變了,只是不是一下子發(fā)生的。

          未來已來,只是不是均勻分布。

          — Gibson//結(jié)束

          原文鏈接:https://medium.learningbyshipping.com/microsoft-office-existential-choices-in-the-face-of-platform-shifts-9ed5847593a4

          編譯組出品。編輯:郝鵬程。

          者:成金之路

          www.cnblogs.com/uttu/p/6384541.html

          本文不涉及復(fù)雜的底層數(shù)據(jù)結(jié)構(gòu),通過explain解釋SQL,并根據(jù)可能出現(xiàn)的情況,來做具體的優(yōu)化,使百萬級(jí)、千萬級(jí)數(shù)據(jù)表關(guān)聯(lián)查詢第一頁結(jié)果能在2秒內(nèi)完成(真實(shí)業(yè)務(wù)告警系統(tǒng)優(yōu)化結(jié)果)。

          希望讀者能夠理解SQL的執(zhí)行過程,并根據(jù)過程優(yōu)化,走上自己的"成金之路"

          需要優(yōu)化的查詢:

          使用explain出現(xiàn)了Using temporary;

          有分頁時(shí)出現(xiàn)了Using filesort則表示使用不了索引,需要根據(jù)下面的技巧來調(diào)整語句

          • rows過多,或者幾乎是全表的記錄數(shù);
          • key 是 (NULL);
          • possible_keys 出現(xiàn)過多(待選)索引。

          1.使用explain語法,對(duì)SQL進(jìn)行解釋,根據(jù)其結(jié)果進(jìn)行調(diào)優(yōu):

          MySQL 表關(guān)聯(lián)的算法是 Nest Loop Join,是通過驅(qū)動(dòng)表的結(jié)果集作為循環(huán)基礎(chǔ)數(shù)據(jù),然后一條一條地通過該結(jié)果集中的數(shù)據(jù)作為過濾條件到下一個(gè)表中查詢數(shù)據(jù),然后合并結(jié)果:

          • EXPLAIN 結(jié)果中,第一行出現(xiàn)的表就是驅(qū)動(dòng)表
          • 對(duì)驅(qū)動(dòng)表可以直接排序,對(duì)非驅(qū)動(dòng)表(的字段排序)需要對(duì)循環(huán)查詢的合并結(jié)果(臨時(shí)表)進(jìn)行排序(Important!),即using temporary;
          • [驅(qū)動(dòng)表] 的定義為:1)指定了聯(lián)接條件時(shí),滿足查詢條件的記錄行數(shù)少的表為[驅(qū)動(dòng)表];2)未指定聯(lián)接條件時(shí),行數(shù)少的表為[驅(qū)動(dòng)表](Important!)。
          • 優(yōu)化的目標(biāo)是盡可能減少JOIN中Nested Loop的循環(huán)次數(shù),以此保證:永遠(yuǎn)用小結(jié)果集驅(qū)動(dòng)大結(jié)果集(Important!)!:A JOIN B,A為驅(qū)動(dòng),A中每一行和B進(jìn)行循環(huán)JOIN,看是否滿足條件,所以當(dāng)A為小結(jié)果集時(shí),越快。
          • NestedLoopJoin實(shí)際上就是通過驅(qū)動(dòng)表的結(jié)果集作為循環(huán)基礎(chǔ)數(shù)據(jù),然后一條一條的通過該結(jié)果集中的數(shù)據(jù)作為過濾條件到下一個(gè)表中查詢數(shù)據(jù),然后合并結(jié)果。如果還有第三個(gè)參與Join,則再通過前兩個(gè)表的Join結(jié)果集作為循環(huán)基礎(chǔ)數(shù)據(jù),再一次通過循環(huán)查詢條件到第三個(gè)表中查詢數(shù)據(jù),如此往復(fù)

          2.兩表JOIN優(yōu)化:

          a.當(dāng)無order by條件時(shí),根據(jù)實(shí)際情況,使用left/right/inner join即可,根據(jù)explain優(yōu)化 ;

          b.當(dāng)有order by條件時(shí),如select * from a inner join b where 1=1 and other condition order by a.col;使用explain解釋語句;

          • 如果第一行的驅(qū)動(dòng)表為a,則效率會(huì)非常高,無需優(yōu)化;
          • 否則,因?yàn)橹荒軐?duì)驅(qū)動(dòng)表字段直接排序的緣故,會(huì)出現(xiàn)using temporary,所以此時(shí)需要使用STRAIGHT_JOIN明確a為驅(qū)動(dòng)表,來達(dá)到使用a.col上index的優(yōu)化目的;或者使用left join且Where條件中不含b的過濾條件,此時(shí)的結(jié)果集為a的全集,而STRAIGHT_JOIN為inner join且使用a作為驅(qū)動(dòng)表

          3.多表JOIN優(yōu)化:

          a.無order by條件時(shí),根據(jù)實(shí)際情況,使用left/right/inner join即可,根據(jù)explain優(yōu)化;

          b.有order by a.col條件時(shí),所有join必須為left join,且每個(gè)join字段都創(chuàng)建索引,同時(shí)where條件中只能有a表的條件,即將其它表的數(shù)據(jù)關(guān)聯(lián)到a中形成一張大表,再對(duì)a的全集進(jìn)行過濾;

          如果不能全使用left join,則需靈活使用STRAIGHT_JOIN及其它技巧,以時(shí)間排序?yàn)槔?/p>

          1)數(shù)據(jù)入庫按照平臺(tái)時(shí)間入庫,自然a的數(shù)據(jù)都按時(shí)間有序;

          SELECT
              c.*, r.HYPERVISOR_HOST_NAME hostname,
              r.HOST_IP
          FROM
              trust_monitor c
          INNER JOIN res_node r ON c.res_node_id = r.ID
          INNER JOIN am_assets a ON r.ASSET_ID = a.ID
          AND a. STATUS = 58
          INNER JOIN se_role s ON a.DEPT_FLAG = s.ROLE_ORG
          AND s.ROLE_ID IN (32, 33, 36, 41)
          WHERE
              c. STATUS = 58
          AND c.changed_type = 79
          ORDER BY
              c.changed_time
          LIMIT 1,
           10;

          兩者結(jié)果一致

          4.誤區(qū):

          a.視圖只是屏蔽或者高效集合多表數(shù)據(jù)的一種方法,視圖與表JOIN,不會(huì)起到任何效果

          參考:

          http://www.cnblogs.com/zhengyun_ustc/p/slowquery1.htmlhttp://huoding.com/2013/06/04/261

          騰訊T4純手打《數(shù)據(jù)結(jié)構(gòu)和算法》源碼筆記,學(xué)完一腳踢進(jìn)大廠


          主站蜘蛛池模板: 国产激情无码一区二区app| 韩国资源视频一区二区三区| 国产午夜精品一区二区三区漫画| 狠狠综合久久av一区二区| 亚洲一区中文字幕在线电影网 | 91福利一区二区| 亚洲日韩国产一区二区三区在线 | 国产一区二区好的精华液 | 丰满岳乱妇一区二区三区| 国产精品被窝福利一区| 精品一区二区三区在线观看| 成人区精品人妻一区二区不卡| 久久精品亚洲一区二区| 国产精品va无码一区二区| 中文字幕日韩一区二区不卡| 一区二区免费在线观看| 国产在线第一区二区三区| 精品国产一区二区三区久久影院 | 国产福利一区视频| 国产综合一区二区| 国产精品va无码一区二区| 亚洲日本精品一区二区| 日韩免费一区二区三区在线| 无码欧精品亚洲日韩一区夜夜嗨 | 日韩中文字幕一区| 麻豆精品一区二区综合av| 久久精品岛国av一区二区无码| 日韩免费一区二区三区在线播放| 国产福利一区二区| 免费精品一区二区三区第35| 青娱乐国产官网极品一区| 国产一区二区视频在线播放| 国产成人一区二区三区视频免费 | 亚洲一区二区三区电影| 国产一区二区精品久久91| 国产无码一区二区在线| 精品三级AV无码一区| 国产一区二区三区免费在线观看 | 日韩在线视频不卡一区二区三区| 精品亚洲一区二区三区在线观看 | 亚洲欧美日韩国产精品一区|