整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
關于MySQL DDL表結構變更，各個工單平臺基本上都支持了pt-osc及Online DDL的方式，但是，我相信仍然有一大部分人，不太了解這兩種方式各自的優缺點是啥，以至于實際當中，會稀里糊涂的隨機選一種去執行，選對了固然好，選錯了，自然免不了領導的一頓K，這......當然是開玩笑的哈。
在各搜索平臺上，介紹關于pt-osc及Online DDL工作原理的文章，不計其數，但是，對于非專業選手而已，又有幾個人是完全吃透的呢？所以，在這，不打算對其原理再重復一遍，僅從他們的執行機制角度出發，介紹各種DDL在選擇不同方式時所產生的影響，并基于此來分析該如何選擇。
另，現在普遍使用的版本為5.7，所以，咱就以 MySQL 5.7.24 版本為例。
?機制：MySQL通過Innodb引擎在內部執行一系列的操作進行表變更，當然，同一個表，不同的DDL，會有不同效果，甚至會出現一天上一個地下的差異，所以不同DDL，后面再對其進行具體分析；如果有從庫，則在主庫執行完成后，從庫再操作一遍，動作和主庫一模一樣（執行時間也很接近）。
?優點：這個咱后面在講具體SQL時再進行具體分析。
?缺點：
?某些場景下，會鎖表引發堵塞增刪改操作，這個是需要重點注意的，具體場景后面會標紅說明。
?如果有從庫，這有一個很致命的弱點：復制延遲。因為主庫執行的動作，會在從庫再來一遍，如果這個動作是非常耗時的，那在從庫執行（重放主庫的動作）的時間點開始，其后續所有動作都被堵塞住，直到從庫也執行完這個DDL后，才會繼續按順序執行其他SQL。這就就意味著，從從庫執行開始，從庫復制就出現了延遲，延遲的時間會慢慢變大，直到DDL執行完后，延遲才會慢慢變小。
?存在數據copy的情況時，需要額外的磁盤空間，但有可能同樣的SQL，空間需求會比使用pt-osc低。
?特殊情況：云側MySQL RDS，本身有一個隱藏從庫用于高可用，因為這個隱藏從庫不對外提供服務，所以基本上業務側也不需要去關注他。但極端情況，如果大表DDL操作使用Online DDL模式時，在隱藏從庫正在執行DDL期間，主庫掛了，那常理就需要切換到隱藏從庫，才能繼續提供服務，但為了保證數據的一致性，隱藏從庫必須要等DDL執行完，再回放DDL之后的binlog，然后，才能將其提升為主庫，對外提供服務，所以這個恢復時間有可能很長。總得來講，這個情況對業務而言也是致命的，只不過概率極低。
?機制：創建一個新臨時表，并在老表上創建3個觸發器，再進行新老表的數據同步，直至新老表數據一致后，再進行表名互換，達到表變更的目的。不同的DDL，只要pt-osc支持，他的操作方式都是一樣的，這點與Online DDL完全不同。
?優點：
?可以設置相應的參數，根據主、從庫負載（比如復制延遲）的情況，動態調整數據拷貝速度，整個表結構變更過程相對比較溫和。
?不會引發從庫復制延遲超級大的情況；
?執行完后，新表會將老表占用的碎片空間完全釋放掉。
?缺點：
?需要將老表的所有數據都拷貝到新表上，這就意味著拷貝期間，磁盤IO可能較高。
?要拷貝全量數據，所以執行時間也會很長。
?新臨時表存放數據也需要空間（最大空間需求可能和原表一樣），拷貝數據時還會產生大量binlog，所以對于本來空間就緊張的實例而言，這方式真的是雪上加霜。
加鎖情況，想必是大家使用時關心較多的一個問題，但是，我想說，MySQL 5.7加鎖情況會比你想象中的要好。Online DDL及pt-osc，大部分情況下，只會在執行前后加表元數據鎖，其在獲取到表元數據鎖并上鎖后，在極短時間內做完后續相關動作，緊接著就會將鎖釋放掉。Online DDL除特殊操作外（后面會說明），大部分情況下，不會對現有業務造成堵塞影響。在業務足夠繁忙時，反而有可能會出現表結構變更操作獲取不到表元數據鎖（鎖等待超時），從而導致執行失敗的情況。
在具體分析后面各種DDL之前，咱統一假設要操作的表足夠大，要不然表太小的話，不管什么方式都是瞬間完成，就沒有對比的意義了。另，編寫的DDL語句，如果想用Online DDL方式，咱也不需要刻意去指定 ALGORITHM 及 LOCK 選項，就讓MySQL自動判斷后默認選擇就好。
下面，咱就從MySQL官方文檔Online DDL對各種操作的支持角度去分析兩種方式的差異情況。當然，如果你的DDL語句同時含有好幾種不同的操作，那就以最壞的那種情形做參考即可。
圖一：Online DDL 索引操作
Online DDL：從圖一，我們可以看出，這會選擇In Place的方式執行，整個過程，只會涉及到拷貝二級索引列相關的數據用于創建索引，所以需要拷貝的數據，相對于pt-osc而已，肯定會少很多，反過來說，執行需要的時間也相對會少。如果沒從庫，不存在復制延遲的問題，那選擇Online DDL顯然會比pt-osc更優；但如果有從庫，那復制延遲的問題，自然是需要考慮的，而且大表復制延遲的時間，當然也會較長，如果接受不了延遲，那直接選pt-osc就好。
pt-osc：復制整個表的數據用于建新表，優勢是有從庫時，幾乎不存在復制延遲的問題；劣勢也很明顯，因為拷貝整個表的數據，所以時間長，同時磁盤IO也會變高。
Online DDL：從圖一可以看到Only Modifies Metadata對應的是YES，也就意味著僅修改元數據，速度非常快，幾乎瞬間完成，必選Online DDL。
pt-osc：直接無視
咱現在使用的索引類型基本上都是BTREE，幾乎很少用到HASH，同時也很少見到有用全文索引及空間索引的，所以，這幾種咱就不討論了。
圖二：Online DDL主鍵操作
因為pt-osc拷貝數據的過程，會依賴于唯一鍵（主鍵或者唯一索引）來校驗數據的一致性，對唯一鍵進行相關的操作可能會引發各種各樣的問題，所以不管pt-osc實際支持或不支持這類操作，咱都直接默認為不支持就好。也就是涉及主鍵及唯一索引相關的操作，都直接選Online DDL。但是，需要注意的是，單獨刪除主鍵的操作，會引發鎖表，導致不允許對表進行其他增刪改的操作，也就是增刪改會被堵塞住，這操作需要慎重考慮。而同一個DDL里面，刪除老主鍵的同時又加上新主鍵，是不會引起堵塞的。
圖三：Online DDL列操作
Online DDL：從圖三可以看出，這6種DDL操作，在選擇Online方式時，都會重建表，效果上與pt-osc并無太大差別，還得擔憂從庫復制延遲的問題，那既然如此，直接選擇pt-osc的方式更省事。
Online DDL以下這幾種情況會鎖表，堵塞其他增刪改操作，需要注意：
1）增加一個自增列。
2）單純修改列類型。
3）修改列名，同時修改了列類型（該情形應該算修改列類型的一個特殊例子）（只支持 Online DDL）。
pt-osc：首選。需要注意的是，因為pt-osc不支持修改列名，所以上述的第三點，只能選擇Online DDL的方式執行，但是選擇Online DDL，又會出現鎖表導致堵塞其他增刪改的操作，所以慎重。
Online DDL：MySQL底層在存儲變長列VARCHAR列的內容時，還會額外記錄內容占用字節數的大小，記錄這個大小，也是需要空間的。另外，還有個東西咱需要了解下，VARCHAR列存儲一個字符，使用utf8字符集時，最大需要3字節（比如存儲一個中文字符），而utf8mb4最大需要4字節（比如存儲一個表情符）。知道了使用什么字符集，咱就可以計算出存儲一個VARCHAR變長列最大需要多少字節了。
列存儲最大需要字節數=VARCHAR列定義的長度 * 不同字符集存儲單個字符需要最大字節數
而記錄列占用字節數大小，所需的空間，會根據 列存儲最大需要字節數 細分出兩種情況：
1）列存儲最大需要字節數為0-255時，記錄列占用字節數大小需要1字節。
2）列存儲最大需要字節數為256-65535時，記錄列占用字節數大小需要2字節。
3）因表數據行，非大對象的列，總的存儲內容長度限制就是65535，所以，單列VARCHAR存儲需求自然也不能超過這個限制，也就是不存在超過65535的情況。
回歸正題，VARCHAR列增加大小：
1）如果列長度增加后，記錄列占用字節數大小所需字節數不變，也就是列存儲最大需要字節數依然在同一個范圍內：0-255或256-65535，那這類操作，ALGORITHM支持使用 In Place算法，只會修改表的元數據信息，瞬間完成，此情形，直接選Online DDL即可。
2）如果列長度增加后，記錄列占用字節數大小所需字節數變了，從1字節變成2字節，ALGORITHM 則只支持COPY算法，這就意味著會出現數據拷貝的情況，同時會堵塞其他增刪改的操作，這情形選pt-osc。
例子：
# 建表
create table t1(name varchar(10) null) charset=utf8mb4;
# 列存儲最大需要字節數計算：長度 10，utf8mb4字符集存儲單字符最大需要字節數 4
# 列存儲最大需要字節數=10 * 4=40
# 記錄列占用字節數大小所需空間為1字節
# 表結構變更一
alter table t1 modify name varchar(63) null;
# 列存儲最大需要字節數計算：長度 63，utf8mb4字符集存儲單字符最大需要字節數 4
# 列存儲最大需要字節數=63 * 4=252
# 記錄列占用字節數大小所需空間依然為1字節，ALGORITHM默認選用In Place，Online DDL執行瞬間完成
# 表結構變更二
alter table t1 modify name varchar(64) null;
# 列存儲最大需要字節數計算：長度 64，utf8mb4字符集存儲單字符最大需要字節數 4
# 列存儲最大需要字節數=64 * 4=256
# 記錄列占用字節數大小所需空間變為2字節，ALGORITHM只能使用COPY，引發數據拷貝，堵塞其他增刪改操作，選擇pt-osc
pt-osc：根據上述信息選合適的。
Online DDL：從圖三可以看出，這類操作會只修改表元數據信息，速度極快，直接選Online DDL方式即可
pt-osc：直接無視
Online DDL：在MySQL 8.0版本前，自增值不存在持久化的概念，修改這個值，只會在內存中修改，更不涉及數據的拷貝及變動，所以直接使用Online DDL方式即可。
pt-osc：直接無視
圖四：Online DDL 虛擬列操作
Online DDL：虛擬列不涉及數據存儲的問題，所以新增和刪除都只會涉及到表元數據的變更，幾乎瞬間完成，直接選用Online DDL方式執行即可。
pt-osc：直接無視
Online DDL：這幾種操作，在選擇Online DDL時，都會涉及到表重建的問題，大表執行時間不會短，另外，新增/修改Generated存儲列 以及 修改Generated虛擬列順序，都會鎖表，引發堵塞其他增刪改操作，所以，建議選pt-osc。
pt-osc：首選
圖五：Online DDL外鍵操作
如果表存在外鍵依賴，后期對父表進行各種DDL操作時，數據庫會有較大的風險，嚴重的甚至會鎖表，所以不建議用外鍵。
圖六：Online DDL表操作
Online DDL：從圖六看出，Online DDL修改表名，只會涉及到修改表的元數據信息，瞬間完成。
pt-osc：不支持
Online DDL：咱對表的操作，常用到的，可能就是表碎片整理、更改行格式（比如改成壓縮模式），修改字符集（含內容轉換）以及收集統計信息，這些操作，從圖六也看到了，基本都是需要重建表，建議首選pt-osc。
pt-osc：首選
其他操作平常基本很少用到，暫時不討論。
圖七：Online DDL表空間操作
在實際使用中，幾乎見不到，咱就不討論了。
圖八：Online DDL表分區操作
表分區相關的操作較多，咱就挑比較常用的進行分析，其他操作不做贅述。
Online DDL：他的本質是新建一個臨時表，每個分區對應一個數據文件，然后進行拷貝，拷貝完畢后，表名互換，刪除老表。眼熟不？從某種程度上講，這個過程與pt-osc是相似的，但是，Online DDL方式會鎖表，堵塞其他增刪改操作，所以，直接選擇pt-osc方式即可。
pt-osc：必選
Online DDL：
新增分區，只分析常用的RANGE及LIST分區。RANGE分區新增分區，有個嚴格的限制，新分區less than的值必須是遞增的，換句話講就是不存在數據拷貝的問題。LIST分區，這個更直接，相關內容如果在LIST分區中不存在，直接不允許插入，新增分區也不存在數據拷貝的問題。所以，這兩種選用Online DDL時，操作幾乎都是瞬時完成的，直接使用Online DDL即可。
刪除分區時，會對當前分區上鎖，堵塞該分區的其他增刪改操作，但既然你都打算刪除分區了，想必自然也不會再對該分區有其他操作。 其對應系統底層的操作，類似于直接將分區對應的物理文件進行刪除，操作時，如果文件足夠大，系統IO會瞬間暴漲，繼而影響業務，所以建議在業務低峰期間進行。
TRUNCATE分區操作，對應系統底層的操作，類似于直接將分區對應的物理文件進行清空，操作時，如果文件足夠大，系統IO會瞬間暴漲，繼而影響業務，所以建議在業務低峰期間進行。
pt-osc：直接無視
從上面的介紹可以看出，DDL相關的操作較多，想要完全記住各種操作選那種方式最合適，想必也是件費神的事情。如果上面信息對你有用，點贊收藏起來，用到時再慢慢參考即可。
參考：
?https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-column-operations?
者按：這個世界上唯一不變的東西只有變化本身。無論是既有者還是顛覆者對變化都很重視。從既有者的角度來說，弄清楚某件事情究竟是平臺轉移還是系統噪聲非常關鍵。因為如果是平臺轉移的話，自己就需要未雨綢繆；如果是系統噪聲，那就不需要浪費太多的資源去應對。從顛覆者的角度來說，除了弄清楚變化的本質以外，知道顛覆會采取什么樣的路徑至關重要。因為很多創意的前景總是非常美好的，但道路卻是非常曲折的。當我們對AI、區塊鏈之類的新興技術做出判斷時，最好是從過去技術發展史汲取經驗。曾領導開發了Office 95、97并擔任過微軟Windows事業部總裁的Steven Sinofsky回顧了Office一路上曾經遭遇的各種挑戰以及生死抉擇，是一個很好的案例參考。
《星際迷航：可汗怒吼》中小林丸的屏幕上詳細列出了Savik面臨的一種“無法取勝”的競爭局面。
這是個玩具。它是下一個大事物。技術很神奇。但技術也是很瑣細的。在討論“區塊鏈”時爭論很容易陷入到抽象之中。
可是如果你正處在一場技術轉變/顛覆之中呢？
這是一個有關微軟Office的故事。
似乎每個人對區塊鏈都有自己鮮明的觀點，基于跟過去的任何形式的類比。如果有人提出區塊鏈是跟互聯網本身一樣大的東西的話，按照很多人的說法，這個人既不懂區塊鏈，也不懂互聯網。
在這里我想分享一個已經持續進行了25年的故事，一場有可能對微軟Office造成“威脅”的平臺轉移，我的目的是希望你從中可以為像區塊鏈這樣的技術在平臺轉移中如何發展，以及實際的顛覆會呈現出一種非常不同的“形態”提出充分的理由。
這是因為在既有市場里，尤其是大型的既有市場里，“下一個大事物”從來都不是用新技術建造的舊事物的新版本。你必須考慮所有的碟子在空中是怎么旋轉的，必須假定一切都有可能發生改變。
到2000年時Office已經連續經歷了長達8年的爆發式增長，那年的收入已經達到了100億美元。產品從個人購買“轉型”到企業購買和IT部署。看起來它的情況安全極了。
現在可能很多人都不記得了但微軟Office其實是一款消費者產品。整個GTM都是跟零售、大規模市場和個人有關，軟件市場就是這樣的。在1990年代中后期，Office（以及Windows NT和Exchange）進行了一次所謂的大規模轉型，朝著企業端發展，并且建立了一個可管理的賬戶銷售模型。
上一代的競爭（Lotus/IBM、Borland、WordPerfect）依然“存在”。新的競爭也來了，也就是開源版的所謂的“開放”Office。我們對自己的執行能力有信心，認為次要/免費產品并不會對我明構成實質威脅。
Office作為個人應用已經發展成羽翼豐滿，每一個都承擔了某一類別的細分功能或者“直面”了不同的競爭對手。在套件的戰爭中，沒有一個主要競爭對手具備完全的有競爭力的套件（文字處理器、電子表格、圖形、數據庫，然后是電子郵件）。鑒于這一歷史，團隊普遍的看法是，直接跟我們沖突的競爭對手或者甚至開源項目對我們構成的競爭威脅都很小。盡管如此，我們還是非常注意OpenOffice，因為他們總是抄我們。我記得有一次在貿易展上我在一個攤位看到了一個演示，我注意到他們的“PowerPoint”菜單跟Office不一樣（還有他們的Excel和Word也是）。當我向他們指出這一點時他們感到很震驚，承諾當天下午會“修復”這個問題。我因此反而沒那么擔憂了，因為他們的想法是克隆Office。
不過它們仍然留住市場上。這里面真正有新意的是這是兩種不同的技術路線的首次競爭。
（1）用Java編寫的Office（同時也是可能的開源，以及WORE——一次編寫隨處運行的首次亮相）
（2）給瀏覽器使用的Office
試著不要用事后諸葛亮的角度去思考該怎么做。
當你已經知道了結果之后是很難從過去的角度去吸取這些經驗教訓的。這對于商學院的學員組隊想從案例研究中學到東西來說是個挑戰。但這個案例方法不是跟特定技術的事實有關，重點是要知道經理和領導如何去決定該怎么辦。所以我們這里討論的焦點也會放在這上面。
說到商學院，當時我正在休假去哈佛商學院教書。學生的直接反映差不多是“Office已死”。這令人震驚。我不斷地問為什么我還在微軟工作。
此外談到商學院那段時間，1998年我正在休假時正值“創新者的窘境”剛剛冒出來，GBS的走廊里個個都在討論顛覆。這就是為什么學生和所有的老師都非常確信Office有可能成為第一個也是最大一個顛覆的犧牲品。因為跟Clay（Clay Christensen，創新者的窘境的提出者）只有幾門之隔，所以那是個非常令人興奮的學期，雖然經常要為微軟辯護。
Java Office與其說是一個產品不如說是一場運動。很多“applet”（Office是應用，applet是按需的精益的小應用）都要“取代”Office。組件化已經成為運動。微軟內部很多人都認為組件架構是未來，尤其對于企業應用來說。
復合工作流與應用，以及用小規模的代碼（跨任何OS）提供的技術吸引力/狂熱非常之高，因為Office是一個龐大的單一程序，是“膨脹軟件”。光是運行SETUP就已經夠痛苦的了。
但是我們曾經試過用“OLE”開發組件，也試過“編輯由不同部分組成的文檔”的辦法，結果完全是個失敗。神奇的彈出菜單，在小矩形框內編輯……
這整個“組件”運動基本上是技術優先的思路。它幾乎是“面向對象”的產物，我在職業生涯的前5年基本上都在“處理”C++（當時對世界來說是個新東西）。認為Office的膨脹和管理困難可以用組件“治愈”的IT專業人士太多了……因為從定義來看組件就應該是更容易或者類似的。
重要的是要認識到IT世界對微軟還不習慣，而當時發生的大事是要“減少總擁有成本”——這個基本上由于Windows+Office導致的，當時IT界的觀念是應該制訂解決方案。認為基于可重用組件開發的解決方案可以促進更快速更靈活的應用。
于是組件雙管齊下對現狀形成了沖擊。同時Java正好又是很新很酷的面向對象編程語言。盡管很多人已經意識到面向對象除了反而拖累了速度并且引入了編程復雜性以外其實對現狀并沒有什么改變，但這一點也無關緊要。
這是Word文檔內部一個Excel組件的截屏。其基本想法是這樣你就不需要在應用/窗口之間來回切換了因此你的目標就是一份很好的打印文檔。只需要點擊菜單和工具欄就會切換到“Excel”然后你就可以編輯電子表格之類的東西了。
那如果下次別人也發現了這種做法之后我們是不是應該對他們有可能摧毀我們感到害怕呢？或者這是不是一切的未來的又一個失敗的信號呢？
這里面的風險相當高！
像上面例子中的組件完全就是個失敗。他們強調PC非常脆弱，而且對于最終用戶來說一般非常笨重。他們給一個“套件”做了一個非常棒的演示，但就僅此而已了。此外它們開發和測試也非常復雜，這令仍然專注于遺留競爭對手的團隊感到極其沮喪。
順便說一句，這些Java Applet對資源的占用通常是Office的10倍，但是能力卻不及后者的1/100。這樣的東西是很難行得通的。這些東西想要成為可靠的替代品或者威脅是非常困難的。
我的天吶這些Java小應用太可怕了。Java很慢，占內存又非常多，而且根本就是很詭異。Office就有很豐富的歷史，尤其是第一個Windows應用使用解釋型語言（類似C）編寫的，團隊后來花了好幾個產品周期才把解釋型語言干掉了。現在Java又跳出來告訴全世界“不，這才是正道。”在我們看來這就是胡扯。@jondevaan的態度尤其鮮明，因為他在解析器上面花費的時間實在是太多了，他一直都想讓Excel跑快一點。對我個人來說，Hava也是垃圾回收這一事實也提供了這是胡扯的充分證據，因為它花了很多年時間攻擊說C++并沒有真正的垃圾回收機制，而真正的面向對象程序員時使用垃圾回收的。
因此你可以看到跟當時WWW和現在的區塊鏈的一些類比，這些新的解決方案在執行那些你知道如何做快的事情上往往執行得非常糟糕。WWW渲染文檔格式很慢，這也難怪，因為這種使用ASCII碼的協議跟文檔格式并沒有太大關系。
但這卻幾乎不能阻止IT、開發者、內部陣營（.net！）的人不斷地主張組件以及用這種新方式重寫Office才是未來。跟這種聲音做斗爭的壓力很大。
記住，這個我們之前已經試過了，所以顯然我們必須早點行動！
極力鼓吹Office應該重寫的戰略思想家和業界權威的數量之多再怎么夸張都不為過。顯然Office已經完蛋了，而他們已經看到了未來。
但是組件、解釋器以及垃圾收集就像是三重彩投注一樣，從這么一個地方開始作為起點簡直是瘋了。
與此同時，Exchange郵件團隊引領了DHTML/AJAX/XMLHttpRequest的潮流，并且將基于瀏覽器的電子郵件帶上了一個新的臺階（用來用于gmail、google map上），這開辟了重塑Office的又一個前沿，針對的主要是Outlook。（注意基本/高級模式——這在DTTML中是可選的）
然后就冒出了Internet Explorer、Dynamic HTML （DHTML）再加上XMLHttpRequest。這似乎就像魔法一樣。它還有一個額外好處就是當時它只有在IE瀏覽器上才能行，IE團隊自然喜歡這一點。
這完全是另一種競爭性挑戰，也是針對Office的一種架構方案。
所以可以想象這又要連續開很多會來進行討論。對于微軟的觀察者來說，.net的人焦點都放在Java而IE的人則關注HTML，兩方都希望Office在這些新平臺上重寫。你可以想象我要出席所有那些會議。
在互聯網時代，Outlook是Office新的靠山，所以這里面的風險很大。
但再次地這要面對距離它很遙遠的功能子集問題，而Outlook的歷史才有3年時間！
盡管這次是一支團隊與另一支團隊之爭。不是組織之間，而是技術策略/架構之爭。
Outlook是全新產品。這東西還幾乎用不了。97年時對它的評測頂多算是不慍不火（請不要讓我Google Walt Mossberg的評測！）。Outlook 98迅速增加了互聯網協議，因此引入了困擾微軟客戶端長達10年的雙產品分裂。然后Outlook 2000又帶來了2種“模式”等等。換句話說，為了讓*Windows*電子郵件能用就夠我們忙的了。
但然后引領/發明了AJAX的Exchange團隊開發出了完美的API來解決Outlook在Windows上面遇到的問題，做法就是向Exchange服務器發送請求并且顯示很多行的電子郵件。這讓Outlook看起來很慢！與此同時Outlook已經在客戶端實現了一堆的功能，所以客戶端/web就很不對稱，這正是客戶所不想看到的。可以證明為什么開發電子郵件的架構是錯誤的材料還有很多。
在外部有很多人都在用Ajax開發基于瀏覽器的創作工具。
這很令IE團隊感到沮喪，因為Office團隊不做AJAX Office應用。所以自然地IE團隊總是非常踴躍地宣傳我們的各種“競爭對手”。平臺就是這樣的！
OWA（outlook web access，無需客戶端直接通過互聯網讀取發送郵件）對于輕量電子郵件很好但不適合支持主流的電子郵件和日歷功能。這也是一個很好的IE展示。于是Yahoo、Hotmail、AOL等開始大力宣傳使用DHTML，很多很酷的演示開始出現，其中就包括開發類似Office之類的東西。PowerPoint（或者畫圖）尤其是個目標。
Office支持作為文件格式的HTML，但不支持作為編輯運行時。協作服務器跟Office配合有大量的工作要做。比方說參見edition.cnn.com/TECH/computing……
Office正面臨3種競爭性顛覆：
免費版
客戶端Java版
瀏覽器/HTML版
每一種的實質是：
a）下一場重大平臺轉移
b）完全是個錯誤的想法
c）可能是正確的想法，但是當時實現還為時尚早
與此同時我們是個體量達100億美元的業務。
圍繞著Java和AJAX的初創企業開始像雨后春筍一樣冒出來。大多數都是采取直接山寨Office的方式。當然，這是我們的看法（偏見）所以風險不大。
整個公司對Office業務都感到非常擔心。提供了很多“幫助”。大公司就是這么運作的。
想象一下，你正在致力于一項10年間從10億美元做到了100億美元并且在每一個細分領域把10多個競爭對手都痛煸了一頓還贏下了Mac和Windows（以及OS/2）兩個市場的業務。現在互聯網似乎突然之間就冒了出來同時你還面臨著Java的架構性競爭以及開源的結構性競爭。而且它們全都直接瞄準了你的薄弱點，擁有成本、復雜性以及膨脹。壓力可想而知。
我不斷地列舉用那些技術做“Office”的所有新產品。任何時候我們的規劃文檔里面都會有各種大表，我們的產品規劃總是在同時研究著十多種競品。似乎每一次貿易展（我們當時還是通過這種渠道去了解）都報道又有新的基于瀏覽器或者Java的Office出來了。
與此同時，內部來自技術專家要求作出回應的呼聲非常高。銷售人員一個都不想要除非時他們正在銷售但去掉了他們反對的（膨脹、TCO）東西。
絕對是Office最困難的時候：我們已經成為守江山的人了，現在要面對無數新的/潛在的風險了。
但是所有這些都沒有用在任何“真正”的東西上，除了Outlook。Google Maps/Gmail還要幾年后才出來呢。
Oracle還折騰“網絡計算機”的概念。Office病毒/惡意軟件破壞了品質。膨脹軟件。WWW機會巨大。
到處都是下一個基本架構。
你能想象Office看起來有多脆弱呢？
機構對今天的區塊鏈又會怎么看呢？
與此同時，那些新東西沒有一個能行的。我的意思是說它們真的都不能工作。且不說OpenOffice抱怨的那些大問題（文件格式兼容性），就連基本的編輯功能都是超級笨重。性能很糟糕。此外大多數人的連接都不好，而每一個以瀏覽器為中心的在線工具都要解決離線使用的問題。這些所謂的顛覆根本顛覆不了。
只是每一位權威和客戶都關注未來，要求給出答案。
賭注：我們已經在服務器端協作投入很大的賭注（SharePoint）。
需要對Office的核心價值賭一把。悄然開始我們自己的HTML客戶端——Office“伴侶”。
想法很簡單：如果有東西正在替代Office的話我們就自己做。
我們的答案是聚焦于我們相信自己能做成的東西。
我們已經開始在HTML身上下注了，那就是很早就在Word和PowerPoint支持它作為一種渲染格式（編輯是后面的事）。冷知識：Word的Internet Assistant for HTML比Netscape 1.0的出來的時間還早。將幻燈片保存為帶有導航按鈕的一系列的JPEG是早期DIY和企業網站的標志。PowerPoint很早就開發了這一插件而且特別流行。
1998年我們已經收購了Vermeer FrontPage，并且非常努力想要把Office文檔的“live web”概念推廣到工作場所。這個的第一次迭代是所謂的“Office Web Server（OWS）”后來演變成為了泛化的FrontPage。OWS屬于Sharepoint的“團隊網站部分”或者我喜歡把它叫做“放文件的地方”。
但新的大賭是開發web版的Word、Excel和PowerPoint——運行在瀏覽器上面并且使能在OWS/SharePoint內編輯真正Office文檔的原生HTML應用。我們知道我們不可能把所有的Office功能都做出來，因為我們已經看到每個人都失敗了而且我們還得兼顧現有的業務。
這是超級困難的，因為大多數HTML應用都是“免費”的，所以甚至做這些否被認為是有風險的。這個是“免費版的Office”嗎？銷售根本就不想要這樣的東西！
但從產品的角度來說，這是值得投資的而且時機合適。但這還不夠。
營銷和銷售隊伍可以說非常害怕“web版的Office”。他們好不容易才在跟這些新流行的競爭對手的戰爭中“贏下”了客戶，所以這幫人最不愿意做的一件事就是回過頭來調整原先簽訂的交易（這些交易是持續多年企業協議的開始，今天我們稱之為SaaS，但當時的說法叫“維保”）。他們的假設是如果微軟做web版Office的話那應該是免費的。其價格應該要比“完全”版的桌面Ofice低，原因是它能做的事情變少了（你懂的，因為價格是按照代碼行數計算的）。
Gmail出來了。Google收購了Writely，2web。并把這些工具植入到gmail1里面。基本上把Office文檔從Google webmail流里面擠掉了。花了6年多的時間才看到這一場景實現。
Office的銷售仍然不受此任何影響。
然后gmail出來了，后續又集成了后來成為Google App的應用服務的早期版本。當時已經進入到2006年了。
記住，Google Appl還處在beta階段，直到2009年末才正式推出，直接產生收入更是八字沒一撇，直到現在針對企業進行大力營銷之后才成為現實。
有人可能在猜那段時間我們有沒有進行過任何自己做還是收購別人的決策……當然我們在不斷提出這些想法。但從收購的角度來說這些這些潛在收購對象沒有一個能行的，而且說實話技術圓鋸也排除了這一點可能性。當Google收購web工具時我們的態度是困惑多過擔心，但我們也知道他們的CEO長期以來的商業策略就是做點事情（Open Offuce！）來干擾并且/或者阻止微軟。所以我們很警覺。而且事實上市面上可以集成進Office Web Sever的Java版或者web版工具都已經被收購完了。所以對既有者來說這是典型的集成挑戰。
下一步是把Office Web App的流程植入到基于瀏覽器的郵件里面。
但是客戶那邊仍然非常關心在功能上能跟原有Office“平起平坐”，此外他們也很在意經濟性（定價）。
在平臺轉移的時候，產品需要發展哪怕企業不能發展/或者不想發展。
我們很多人已經從類似IE和Office這樣的地方轉移出去并且現在占據了Windows（以及“Windows Live”）領地工作的地方。所以自然地我們早期做的一件事情是將Office Web App連接上Hotmail和OneDrive（Skydrive），以此來與gmail競爭（當時Hotmail正在與龐大/免費的郵箱做斗爭）。
對免費Office的恐懼很強烈。即便web app的存在也被視為有可能對Office的定價形成不好的壓力。顯然產品團隊沒有經過銷售與營銷挑戰是普遍認識。
今天的Office大概是350億美元的業務。Google Docs很大但是甚至連它的10%都不到。Office Web App很棒但絕大部分人的生產力工具仍然以桌面Office為主。
從中可以得到哪些經驗教訓呢？相當微妙。很容易可以看出這是雙向的。
這段時間我們還對Office下了另一個賭注，“托管Exchange”。這是完全是故事的另外一支了，但是故事的脈絡跟這個十分類似，也是“必須要”與“不能要”以及“沒法用”之間的決策。
不管是有意為之還是出于競爭的必要性因為直接對抗是沒有用的，Google Docs（現在的G-Suite）已經走上了一條不同的發展方向。專注于實時協作，淡化跟Office的直接競爭，并且開發不同的功能加上大規模的免費“分發”，這吸引了大量的受眾。不過賺的錢就不是很多了。Google并沒有報告G-Suite的收入情況但這是Google 40億美元左右其他業務板塊的一部分，里面也許包含了Cloud、硬件等。我這里是猜的。
平臺轉移已經發生。這不是Office克隆、基于Java的克隆或者基于瀏覽器的克隆。
它的發展軌跡跟朝著移動、app、聊天應用以及實時協作轉移的走勢不一樣。
工作的本質正在改變，工具也在引領和跟隨。
最終平臺轉移并沒有來自Java或者甚至基于瀏覽器的編輯/創作工具（也不來自DHTML/Ajax）。顛覆之所以發生是因為很多活動件。
尤其是移動形態因子以及聊天app的崛起改變了生產力實質的版圖。現在正在發生但一直都在持續進行中。
這里有一篇文章是我寫的，里面談到了工作本質的變化——持續生產力：在新時代工作的新工具和新手段。
關鍵跟這個話題的始作俑者有關，區塊鏈，這種顛覆發生在另外一個跟傳統智慧描述不同的抽象層面。它發生在更高的“app”層面而不是純粹的技術層面。這是因為新一代的工具制造者的出現以及技術棧和基于此的應用的出現，但是并沒有把技術棧視為差異化的因素。關鍵在于技術棧能做什么。
當重大轉變發生時，一切都會變化，不僅僅只是技術。
WWW并不僅僅只是改變了客戶端/服務器使用的協議，或者文檔的格式。“一切”都變了，只是不是一下子發生的。
未來已來，只是不是均勻分布。
— Gibson//結束
原文鏈接：https://medium.learningbyshipping.com/microsoft-office-existential-choices-in-the-face-of-platform-shifts-9ed5847593a4
編譯組出品。編輯：郝鵬程。
者：成金之路
www.cnblogs.com/uttu/p/6384541.html
本文不涉及復雜的底層數據結構，通過explain解釋SQL，并根據可能出現的情況，來做具體的優化，使百萬級、千萬級數據表關聯查詢第一頁結果能在2秒內完成(真實業務告警系統優化結果)。
希望讀者能夠理解SQL的執行過程，并根據過程優化，走上自己的"成金之路"
需要優化的查詢：
使用explain出現了Using temporary；
有分頁時出現了Using filesort則表示使用不了索引，需要根據下面的技巧來調整語句
MySQL 表關聯的算法是 Nest Loop Join，是通過驅動表的結果集作為循環基礎數據，然后一條一條地通過該結果集中的數據作為過濾條件到下一個表中查詢數據，然后合并結果：
a.當無order by條件時，根據實際情況，使用left/right/inner join即可，根據explain優化 ；
b.當有order by條件時，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解釋語句；
a.無order by條件時，根據實際情況，使用left/right/inner join即可，根據explain優化；
b.有order by a.col條件時，所有join必須為left join，且每個join字段都創建索引，同時where條件中只能有a表的條件，即將其它表的數據關聯到a中形成一張大表，再對a的全集進行過濾；
如果不能全使用left join，則需靈活使用STRAIGHT_JOIN及其它技巧，以時間排序為例：
1)數據入庫按照平臺時間入庫，自然a的數據都按時間有序；
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;兩者結果一致
a.視圖只是屏蔽或者高效集合多表數據的一種方法，視圖與表JOIN，不會起到任何效果
http://www.cnblogs.com/zhengyun_ustc/p/slowquery1.htmlhttp://huoding.com/2013/06/04/261
騰訊T4純手打《數據結構和算法》源碼筆記，學完一腳踢進大廠
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
