、前言

關(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)樗麄兛偸浅覀儭Ｎ矣浀糜幸淮卧谫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ù)炅恕Ｋ詫?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)大廠