1. Atlas是什么一個讓數(shù)據(jù)庫變更不再“失控”的遷移工具1.1 先說我遇到的一個真實遷移事故如果你維護過幾年數(shù)據(jù)庫大概率見過這種場景測試環(huán)境和生產(chǎn)環(huán)境的表結(jié)構(gòu)悄悄對不上了問了一圈沒人知道誰動過git記錄里也查不到任何ALTER TABLE。我在一個老項目里接管第一周就碰到了更離譜的是同事還很淡定地說了一句“哦那個字段我直接在庫里加了”。這句話幾乎是所有數(shù)據(jù)庫遷移事故的開端。表結(jié)構(gòu)一旦脫離代碼庫、脫離了評審和記錄后續(xù)的聯(lián)調(diào)、發(fā)版、數(shù)據(jù)修復(fù)都會變得極其被動。我當時把所有環(huán)境的schema導(dǎo)出來一對比差異比想象中大得多少了一個索引、多了一個廢棄字段、某個字段類型兩邊不一致連外鍵約束都對不上。這種問題靠人肉核對根本解決不徹底我需要的是一個能把數(shù)據(jù)庫結(jié)構(gòu)變更當成“代碼評審”一樣管理的工具。折騰了一圈之后我最終在工作中把Atlas作為主力方案穩(wěn)定用了下來。Atlas是一個開源的數(shù)據(jù)庫Schema管理工具Go語言編寫核心思路是“Schema as Code”也就是把數(shù)據(jù)庫結(jié)構(gòu)當成代碼來定義、評審、版本化、自動化執(zhí)行。它支持MySQL、PostgreSQL、MariaDB、SQLite、SQL Server、ClickHouse這些主流數(shù)據(jù)庫也支持從ORM模型反向生成結(jié)構(gòu)后端開發(fā)、DBA、DevOps工程師都能從中受益。1.2 數(shù)據(jù)庫遷移的核心難點到底在哪里傳統(tǒng)意義上的數(shù)據(jù)庫遷移工具并不少Flyway、Liquibase都是老牌方案。但我在實際使用中感覺它們解決的是“腳本怎么按順序執(zhí)行”的問題卻沒有回答一個更前置的問題腳本本身怎么來、怎么保證腳本和真實環(huán)境的意圖一致。舉個例子Flyway的典型用法是你手寫一大批SQL腳本V1__create_users.sql、V2__add_posts_table.sql然后工具按照版本號依次執(zhí)行。這套流程本身沒毛病但它有幾個隱含痛點。第一腳本是“增量”的可數(shù)據(jù)庫的最終狀態(tài)不在代碼里。一個新同事接手項目想知道當前庫到底長什么樣他得把幾十個腳本從頭到尾讀一遍還得在腦子里模擬執(zhí)行結(jié)果。要是中途有人在某個版本里夾帶了一個跟腳本不匹配的手工改動那更是災(zāi)難。第二手寫腳本容易漏約束。我今天加一張表忘了帶上外鍵明天上線前才被DBA發(fā)現(xiàn)重新補一個遷移腳本。這種低級錯誤在緊張的發(fā)版周期里很常見而你很難用自動化手段去校驗?zāi)_本的質(zhì)量。第三手工改庫的排查成本極高。即使團隊定了“禁止直連數(shù)據(jù)庫改結(jié)構(gòu)”的規(guī)矩總有人會在半夜因為緊急問題破例。這個操作可能完全沒有留下痕跡等到schema drift結(jié)構(gòu)漂移發(fā)生的時候誰都不知道該從哪里查起。Atlas針對這些痛點做了一件很不一樣的事它不再以“操作步驟”為中心而是以“目標狀態(tài)”為中心。你告訴Atlas“我想要的最終表結(jié)構(gòu)是什么樣”它負責去和當前的數(shù)據(jù)庫狀態(tài)做對比算出中間到底需要執(zhí)行哪些DDL然后再幫你執(zhí)行。這個思路上的轉(zhuǎn)變直接改變了整個數(shù)據(jù)庫變更的生產(chǎn)方式。1.3 Atlas能做什么適合誰來用Atlas提供的核心能力可以分成三大塊。第一塊是聲明式管理。你在HCL文件或SQL文件里描述目標schema運行一條命令A(yù)tlas自動計算出當前庫和目標狀態(tài)的差異生成遷移計劃并執(zhí)行。這個能力適合開發(fā)環(huán)境下快速迭代改完結(jié)構(gòu)馬上就能生效。第二塊是版本化遷移。Atlas可以把“當前庫到目標狀態(tài)”的差異輸出成一個帶版本號的SQL遷移文件。你仍然可以像Flyway那樣按版本執(zhí)行遷移但腳本不是手寫的而是由工具基于真實差異生成的這大大降低了腳本遺漏和錯誤的風險。第三塊是遷移的CI集成。Atlas自帶一個migrate lint命令能夠在代碼合并之前自動檢查這條遷移SQL是否有破壞性變更比如刪了列、改了類型、在已有唯一約束上做不可逆操作等。這個能力對中大型團隊來說價值非常大相當于給數(shù)據(jù)庫變更加了一道自動化評審關(guān)卡。適合使用Atlas的人群也很明確如果你是一個項目的后端開發(fā)受夠了和DBA來回確認表結(jié)構(gòu)如果你是DBA想統(tǒng)一管理幾十個服務(wù)各自的數(shù)據(jù)庫變更記錄如果你做DevOps希望把數(shù)據(jù)庫遷移也納入GitOps流程讓每一次結(jié)構(gòu)變更都走CI/CD。這三個角色使用Atlas都能明顯節(jié)省時間。接下來我把它的核心設(shè)計思路拆開講一講你就能理解它為什么能解決這些問題。2. 核心思路拆解聲明式與版本化兩種工作流的底層邏輯2.1 聲明式工作流描述“目標狀態(tài)”而不是“操作步驟”聲明式Declarative這個詞如果聽著陌生你可以把它和命令式放在一起對比。傳統(tǒng)腳本是命令式的先建users表再建posts表再給posts加外鍵每一步都寫清楚。聲明式則相反你只描述最終的樣子“users表要有這些字段posts表要引用users表?！盇tlas拿到這個目標描述后會連接當前數(shù)據(jù)庫把真實結(jié)構(gòu)和目標結(jié)構(gòu)做對比計算出一個“從現(xiàn)狀到目標”的遷移計劃。如果庫里之前沒有這張表它就生成CREATE TABLE如果字段類型從varchar(255)變成了text它就生成ALTER TABLE如果目標里已經(jīng)刪掉了某個字段它就生成DROP COLUMN。我拿裝修來打個比方。傳統(tǒng)遷移腳本像是施工日志第3天砌了墻第7天刷了漆第12天換了水管。日志記錄得很清楚但你要是想知道最后房子長什么樣得從頭到尾讀一遍。聲明式更像是拿到一張最終設(shè)計圖紙施工隊按圖施工中間哪一步該做什么他們自己算。這套思路的最大優(yōu)勢是消除了“中間步驟”和“最終狀態(tài)”之間的偏差。我只需要維護一份干凈的schema定義文件它既是唯一事實來源也是代碼評審的對象。不再有人能繞過評審悄悄在庫里加字段因為一旦改了庫里的結(jié)構(gòu)下次運行Atlas時它就會把這個漂移暴露出來。不過聲明式也有它的適用邊界。它更適合開發(fā)環(huán)境、測試環(huán)境或者說允許“直接修改結(jié)構(gòu)”的場景。生產(chǎn)環(huán)境通常需要嚴格的變更審批和可回滾記錄這時候你不想直接對生產(chǎn)庫apply一份全量diff你更希望它生成一個最小化的、經(jīng)過評審的SQL腳本然后由發(fā)布系統(tǒng)去執(zhí)行。這就引出了Atlas的第二種工作流——版本化遷移。2.2 版本化工作流生產(chǎn)環(huán)境下更穩(wěn)妥的腳本管理方式Atlas的版本化工作流并沒有丟掉傳統(tǒng)遷移工具的長處。它依然使用目錄結(jié)構(gòu)管理遷移文件每個文件有版本號、有注釋、有校驗和執(zhí)行過的遷移會被記錄在atlas.sum和數(shù)據(jù)庫的一張遷移記錄表里。區(qū)別在于這些SQL遷移文件是Atlas自動生成的不是靠人肉手寫的。實際操作中我會先維護一份HCL或SQL格式的目標schema文件改完之后執(zhí)行atlas migrate diff。Atlas會把“當前數(shù)據(jù)庫狀態(tài)”和“目標schema狀態(tài)”做一次對比然后把差異生成為一個新的SQL遷移文件比如20240908120000_add_status_column.sql。這個文件會包含完整的DDL語句我可以打開檢查確認無誤后提交到git走正常的代碼評審流程。這套流程的優(yōu)勢很明顯。首先遷移腳本永遠和當前schema定義保持同步因為它是從同一個狀態(tài)模型推導(dǎo)出來的其次腳本質(zhì)量有了基本保障因為工具會自動補齊那些容易遺漏的約束和索引最后人仍然擁有最終決策權(quán)我可以選擇性地修改生成的SQL把它調(diào)整得更符合團隊的規(guī)范。我在團隊里經(jīng)常做的一個類比是Atlas的版本化流程相當于你在開發(fā)環(huán)境里隨便改代碼最終上生產(chǎn)前IDE幫你自動格式化、自動檢查語法、自動生成了diff。只不過這里的東西不是代碼而是數(shù)據(jù)庫結(jié)構(gòu)。2.3 為什么選擇Atlas與Flyway、Liquibase等老牌工具的對比很多朋友會問我既然Flyway和Liquibase已經(jīng)存在這么多年了為什么還要折騰一個新工具。我的觀點是老牌工具解決的是“腳本執(zhí)行問題”而Atlas解決的是“腳本生產(chǎn)問題”兩者根本不在同一層。下面這張對比表可以比較直觀地看出差異。維度傳統(tǒng)遷移工具Flyway/LiquibaseAtlas遷移腳本來源人工手寫SQL或XML/DSL自動對比生成也可手寫再納入管理核心抽象按版本執(zhí)行的腳本列表目標schema狀態(tài) 差異計算狀態(tài)核對通過執(zhí)行記錄判斷腳本是否跑過可以直接對比數(shù)據(jù)庫真實結(jié)構(gòu)結(jié)構(gòu)漂移檢測沒有內(nèi)置能力聲明式apply時自動暴露差異CI遷移檢查需要自己寫規(guī)則或依賴第三方內(nèi)置migrate lint檢測破壞性變更多數(shù)據(jù)庫支持較全MySQL、Postgres、SQLite、SQL Server等ORM集成需要額外同步可從ORM模型生成schema或反向生成模型這里補充一個我自己的使用感受Flyway在處理已存在的腳本時很穩(wěn)定畢竟它做的就是順序執(zhí)行和記錄?？梢坏┠愕臄?shù)據(jù)庫已經(jīng)發(fā)生過手工變更或者項目從老代碼接手Flyway的執(zhí)行記錄表和真實schema之間非常容易對不上這時候你只能靠人工修復(fù)歷史表。Atlas由于支持直接對真實庫和目標狀態(tài)做diff處理這類歷史遺留問題反而輕松得多。2.4 diff算法與dev-url臨時計算引擎是靈魂Atlas底層最值錢的部分其實是它計算schema差異的那套邏輯。表面看是“兩個結(jié)構(gòu)做對比”實際要處理的東西非常多字段類型映射、默認值變化、索引命名規(guī)則、外鍵約束變更、各數(shù)據(jù)庫方言的差異全都要考慮進去。為了讓差異計算足夠準確Atlas需要在一個真實可運行的數(shù)據(jù)庫上“演練”一遍。它把當前的schema實現(xiàn)在一個數(shù)據(jù)庫里再把目標schema在另一個數(shù)據(jù)庫里實現(xiàn)然后統(tǒng)一歸一化后再做diff。那個用來做計算但沒有業(yè)務(wù)數(shù)據(jù)的庫就是--dev-url參數(shù)里配置的臨時庫。我第一次用的時候也困惑為什么不能直接拿本地已有的開發(fā)庫當diff基準非得單獨搞一個dev-url。后來才弄明白開發(fā)庫里的臟數(shù)據(jù)、多余測試表、各種歷史殘留都會影響diff結(jié)果甚至可能導(dǎo)致生成錯誤的遷移腳本。用一個專用的臨時數(shù)據(jù)庫每次執(zhí)行命令時清空重建才能保證計算結(jié)果不受到無關(guān)信息的干擾。Atlas還支持一種非常便捷的寫法--dev-url dockermysql://mysql:8.0/test它會在執(zhí)行時自動通過Docker拉起一個MySQL 8.0容器跑完計算后自動銷毀。這在本地開發(fā)時特別方便不用為了diff單獨維護一個數(shù)據(jù)庫實例也避免了環(huán)境差異問題。3. 實操把Atlas接入真實項目的完整流程3.1 環(huán)境準備安裝、容器和初始化紙上談兵沒有意義我直接用一套完整的實操流程來演示。我以MySQL 8.0為例系統(tǒng)是macOS其他操作系統(tǒng)只是安裝命令不同后續(xù)流程基本一致。安裝Atlas主要有兩種方式。macOS上我用Homebrew一條命令搞定brew install ariga/tap/atlasLinux系統(tǒng)可以用官方安裝腳本curl -sSf https://atlasgo.sh | sh裝完之后驗證一下版本atlas version接下來準備一個本地MySQL實例。我會用Docker起一個干凈的容器注意這里不需要掛載任何數(shù)據(jù)卷因為這個庫就是用來做演示和dev計算的用完隨時可以刪掉重建。docker run --name atlas-demo -e MYSQL_ROOT_PASSWORDpass -e MYSQL_DATABASEexample -p 3306:3306 -d mysql:8.0啟動完成后確認一下端口和連接信息。我習慣用環(huán)境變量管理連接串后面命令里統(tǒng)一用mysql://root:passlocalhost:3306/example這種方式避免每次都敲一大串。3.2 聲明式實操用HCL定義第一個schema并完成apply先在工作目錄里創(chuàng)建一個schema定義文件命名為atlas.hcl。這里演示一個最簡單的博客系統(tǒng)結(jié)構(gòu)包含用戶表和文章表并帶上外鍵和索引。schema example { comment blog example schema } table users { schema schema.example column id { type bigint auto_increment true } column email { type varchar(255) null false } column name { type varchar(100) null false } primary_key { columns [column.id] } index idx_users_email { unique true columns [column.email] } } table posts { schema schema.example column id { type bigint auto_increment true } column user_id { type bigint null false } column title { type varchar(255) null false } column content { type text } column created_at { type timestamp null false default sql(CURRENT_TIMESTAMP) } primary_key { columns [column.id] } index idx_posts_user_id { columns [column.user_id] } foreign_key fk_posts_user { columns [column.user_id] ref_columns [table.users.column.id] on_delete CASCADE } }文件寫好后執(zhí)行聲明式apply命令atlas schema apply \ -u mysql://root:passlocalhost:3306/example \ --to file://atlas.hcl \ --dev-url dockermysql://mysql:8.0/test命令執(zhí)行后Atlas會打印出一個SQL計劃包括創(chuàng)建兩張表、對應(yīng)的索引和外鍵。它會問你是不是確認執(zhí)行輸入y回車。第一次跑的時候看到這個交互式確認你可能會覺得多此一舉但它其實是防止誤操作的第一道防線尤其是當你一不小心把--to和-u的地址寫反的時候。完成后連接進MySQL看看users表和posts表已經(jīng)建成外鍵和索引也都在。到這里聲明式工作流的基本閉環(huán)已經(jīng)跑通了。3.3 版本化實操從migrate diff到migrate apply的完整鏈路聲明式適合開發(fā)期但要在生產(chǎn)環(huán)境發(fā)版我們還需要把它轉(zhuǎn)成版本化遷移文件。操作方法很簡單先初始化遷移目錄atlas migrate diff init \ --dir file://migrations \ --to file://atlas.hcl \ --dev-url dockermysql://mysql:8.0/test這條命令會在當前目錄生成一個migrations文件夾里面包含一個初始遷移SQL文件。文件名格式類似20240908120000.sql第一行通常是-- create users table這樣的注釋后面是完整的DDL語句。同時還會生成一個atlas.sum文件它是遷移目錄的校驗和文件用來保證遷移文件在提交后不會被任何人偷偷修改。接著我改一下atlas.hcl給posts表加一個status字段column status { type varchar(20) null false default draft }再次生成增量遷移atlas migrate diff add_status_column \ --dir file://migrations \ --to file://atlas.hcl \ --dev-url dockermysql://mysql:8.0/testAtlas會生成一個新的遷移文件內(nèi)容大致是-- modify posts table ALTER TABLE posts ADD COLUMN status varchar(20) NOT NULL DEFAULT draft;在開發(fā)環(huán)境執(zhí)行遷移atlas migrate apply \ --dir file://migrations \ -u mysql://root:passlocalhost:3306/exampleapply命令會自動計算哪些遷移還沒執(zhí)行按順序執(zhí)行并在數(shù)據(jù)庫里記錄執(zhí)行歷史。這里有一點值得注意Atlas默認會在庫中創(chuàng)建一張atlas_schema_revisions表來記錄已經(jīng)執(zhí)行過的遷移版本。你不需要手動初始化這張表工具會自動完成。3.4 參數(shù)解析幾個高頻flag的真實含義Atlas的命令行參數(shù)看起來很簡潔但真正用起來有幾個flag值得仔細說明因為它們直接決定你的操作是否安全。--to參數(shù)表示目標狀態(tài)可以是HCL文件、SQL文件也可以是一個數(shù)據(jù)庫連接串。比如--to mysql://root:passlocalhost:3306/target意思是以另一個數(shù)據(jù)庫的狀態(tài)作為目標。這在做庫與庫之間的結(jié)構(gòu)同步時非常有用。--dev-url參數(shù)前面提過是差異計算用的臨時庫。使用時建議加上具體的數(shù)據(jù)庫版本比如dockermysql://mysql:8.0/test這樣Atlas拉起的容器就跟你的目標庫版本一致類型推斷才準確。如果你用的是PostgreSQL就把鏡像換成postgres:16。--dir指定遷移目錄格式通常是file://migrations。除了本地文件系統(tǒng)Atlas還支持將遷移目錄存儲在S3、GCS等對象存儲里這為跨團隊共享遷移狀態(tài)提供了便利。--revisions-schema參數(shù)用來指定遷移記錄表所在的位置。如果你一個數(shù)據(jù)庫實例上跑了多個業(yè)務(wù)庫建議給每個業(yè)務(wù)指定不同的記錄表schema避免互相覆蓋。比如atlas migrate apply \ --dir file://migrations \ -u mysql://root:passlocalhost:3306/example \ --revisions-schema example_migrations--dry-run參數(shù)則讓你在真正執(zhí)行前先看到SQL計劃而不落庫。我建議你在任何手動操作之前都先跑一次dry-run尤其是生產(chǎn)環(huán)境。線上直接執(zhí)行DDL的勇氣往往會在第一次看到意外生成計劃時大打折扣。4. 團隊協(xié)作與CI/CD讓數(shù)據(jù)庫變更像應(yīng)用代碼一樣被評審4.1 在CI里自動執(zhí)行migrate lintAtlas真正讓我覺得“值得推廣到全團隊”的是它的migrate lint能力。它可以掃描待執(zhí)行的遷移文件分析其中是否存在破壞性變更常見的檢測項包括刪除列、修改列類型、在已有數(shù)據(jù)上設(shè)置NOT NULL、刪除表等。在本地跑lint很簡單atlas migrate lint \ --dir file://migrations \ --dev-url dockermysql://mysql:8.0/test \ --latest 1這個--latest 1的意思是只檢查最近一個遷移文件因為在PR場景下我們關(guān)心的是這次改動引入的問題而不是歷史遺留問題。lint會把問題分類為Error和Warning遇到ErrorCI就應(yīng)該直接失敗。為了讓這條命令在CI里生效我一般會在GitHub Actions的workflow里面加一個job。核心步驟大致如下- name: Checkout uses: actions/checkoutv4 - name: Setup Atlas uses: ariga/setup-atlasv0 - name: Run migration lint run: | atlas migrate lint \ --dir file://migrations \ --dev-url dockermysql://mysql:8.0/test \ --latest 1這里--dev-url用dockermysql://這種模式CI機器上只要有Docker或者兼容環(huán)境Atlas就能自動拉起臨時數(shù)據(jù)庫來完成分析不需要額外維護一個長期運行的數(shù)據(jù)庫實例。4.2 多環(huán)境發(fā)布流程dev、staging、prod三個階段怎么分工在實際團隊協(xié)作中我推薦把數(shù)據(jù)庫變更流程拆成三個階段。開發(fā)階段所有人只維護atlas.hcl和本地數(shù)據(jù)庫可以使用聲明式apply隨意迭代目標是快速原型。這個階段的數(shù)據(jù)庫結(jié)構(gòu)不追求穩(wěn)定因為還不是評審對象。進入測試或staging階段后通過atlas migrate diff生成正式的遷移腳本提交到git經(jīng)過代碼評審和migrate lint檢查然后由CI自動執(zhí)行到staging庫。到這里結(jié)構(gòu)變更已經(jīng)被完整記錄在案可以追溯到具體的提交人。發(fā)布到生產(chǎn)環(huán)境時我不會讓CI直接自動執(zhí)行DDL而是把遷移命令放在發(fā)布流程中的一個手動確認步驟。比如用ArgoCD、Jenkins或者GitHub Actions的environment審批機制由DBA或具備權(quán)限的工程師點擊確認后再執(zhí)行atlas migrate apply指向生產(chǎn)庫。為什么這么謹慎因為DDL一旦執(zhí)行就很難回滾尤其是刪除列或修改數(shù)據(jù)類型的操作。多一道人工確認多一分安全。這套流程跑通之后數(shù)據(jù)庫變更就不再是“上線的驚險時刻”了。它和普通代碼變更一樣有設(shè)計、有評審、有檢查、有記錄一切都有據(jù)可查。4.3 多人協(xié)作時容易踩的坑沖突與sum校驗多人在同一個項目里協(xié)作遷移目錄的沖突幾乎是必然的。兩個人同時改了atlas.hcl各自生成了遷移文件都提交到了一個分支里這時候就會出現(xiàn)版本沖突。Atlas有一個機制特別“硬核”任何遷移文件或目錄結(jié)構(gòu)變動都會導(dǎo)致atlas.sum校驗和變化。如果我在本地執(zhí)行atlas migrate apply發(fā)現(xiàn)目錄里的內(nèi)容和atlas.sum不匹配命令會直接報錯拒絕執(zhí)行。這個校驗和相當于給遷移目錄上了一把鎖防止文件被手工篡改或者意外修改。遇到?jīng)_突后的正確做法是先把遠端最新的遷移目錄拉下來重新執(zhí)行一次atlas migrate diff讓Atlas根據(jù)最新的目標狀態(tài)和歷史遷移重新計算差異生成一個新的遷移文件。不要手動去調(diào)整已有的遷移文件因為一旦動了老的遷移文件校驗和就會對不上并且進過生產(chǎn)環(huán)境的遷移腳本是不允許反悔的。我還在團隊里定了一條約定生成遷移文件之前先git pull確認遷移目錄是最新的。這個習慣雖然簡單卻能避免大部分沖突。5. 常見問題與排查技巧實錄5.1 高頻報錯排查dev-url、權(quán)限、mismatch用Atlas這一年多我在各種環(huán)境下踩過不少坑下面幾類是最常遇到的。第一類是--dev-url連接不上或者Docker鏡像無法拉取。這個問題通常發(fā)生在新機器上本地沒有Docker環(huán)境或者鏡像源不穩(wěn)定。解決方法是先確保Docker可用或者改用本地已有的數(shù)據(jù)庫實例作為dev庫比如mysql://root:passlocalhost:3306/test。第二類是執(zhí)行atlas schema apply時報權(quán)限不足。Atlas需要創(chuàng)建臨時表、執(zhí)行DDL因此連接用戶需要具備DDL權(quán)限。如果使用的是云數(shù)據(jù)庫還要注意賬號是否有ALTER、CREATE、INDEX等權(quán)限。這個問題在只讀賬號上特別常見建議直接用高權(quán)限賬號跑遷移跑完再回收權(quán)限。第三類是atlas.sum mismatch錯誤。這個原因幾乎都是有人手動修改了遷移文件或者本地遷移目錄和遠端不一致。排查方法很簡單重新git pull然后刪除本地多余的遷移文件確保目錄內(nèi)容與遠端完全一致再重新生成遷移。第四類是diff生成結(jié)果不符合預(yù)期比如應(yīng)該ALTER TABLE卻生成了DROP TABLE再CREATE TABLE。這種情況多半是--dev-url指向了一個非空的數(shù)據(jù)庫里面已經(jīng)有殘留的表結(jié)構(gòu)干擾了對比結(jié)果。解決辦法是使用一個干凈的dev庫或者用dockermysql://動態(tài)創(chuàng)建臨時庫保證每次計算從零開始。5.2 大表DDL怎么處理鎖表風險與替代方案任何遷移工具在執(zhí)行DDL時都需要數(shù)據(jù)庫本身支持對應(yīng)的在線變更能力。Atlas生成的SQL是標準DDL它不會替你解決大表鎖的問題。比如在MySQL 5.7上給一張幾千萬行的表加索引默認的ALTER TABLE可能鎖住整個表的寫入業(yè)務(wù)側(cè)會瞬間出現(xiàn)大量超時。如果你負責的業(yè)務(wù)表已經(jīng)達到億級我的建議是不要在遷移常規(guī)流程里直接執(zhí)行這些DDL而是借助Percona Toolkit的pt-osc或者GitHub開源的gh-ost來執(zhí)行。Atlas生成的遷移SQL仍然可以作為這些工具的目標定義但執(zhí)行層面由pt-osc或gh-ost通過分批拷貝數(shù)據(jù)、在線變更的方式完成。如果你的數(shù)據(jù)庫是MySQL 8.0情況會好很多。MySQL 8.0支持INSTANT ADD COLUMN有些加列操作可以在不重建表的情況下瞬間完成但也不是所有DDL都能用INSTANT算法。建議在發(fā)版前先跑一次EXPLAIN或者查看官方文檔確認這條DDL是否會鎖表再決定是否要走常規(guī)流程。在代碼層面我推薦在遷移腳本中盡量避免以下操作給大表新增帶默認值的NOT NULL列、修改主鍵類型、在未分區(qū)的表上重建索引、大批量UPDATE配合DDL。能用新增表加任務(wù)遷移的就不要直接改大發(fā)收尾。5.3 一些其他經(jīng)驗臨時表、批量操作、升級注意如果你在遷移腳本里使用臨時表千萬注意Atlas的diff計算會把臨時表也納入狀態(tài)對比。這會導(dǎo)致一個很坑的結(jié)果遷移執(zhí)行完后目標狀態(tài)下已經(jīng)沒有臨時表了但實際數(shù)據(jù)庫里臨時表還在下一次diff又會對不上。解決方案是臨時表操作盡量放在存儲過程或者事務(wù)里讓它們生命周期足夠短不要殘留在schema狀態(tài)中。批量操作也要小心。Atlas不會阻止你在遷移文件中寫多語句但一個遷移文件里塞幾十條DDL一旦執(zhí)行到一半失敗恢復(fù)起來非常痛苦。我在團隊里強制規(guī)定一個遷移文件只做一個邏輯變更。新增一張表帶索引外鍵算一個變更加字段算一個變更分開生成。這樣即使某個遷移失敗影響面也最小。版本升級方面Atlas本身迭代速度很快大版本之間遷移邏輯可能有調(diào)整。升級工具前先看一下官方變更日志并在測試環(huán)境完整跑一遍遷移流程確認生成的diff結(jié)果和舊版本一致再決定是否升級。我遇到過Atlas升級后生成的HCL格式發(fā)生變化導(dǎo)致舊文件無法直接使用的情況所以版本固定也很重要CI里的setup-atlas最好指定版本號。6. 最后分享幾個我現(xiàn)在的工作流小習慣6.1 聲明式與版本化怎么配合很多人把聲明式和版本化當成兩個互斥的選擇但我的實際使用感受是它們更像是開發(fā)流程的兩個階段。日常開發(fā)中我用聲明式在本地快速建表、改字段享受“改HCL文件然后直接apply”的暢快感。功能穩(wěn)定、準備提測時我才用atlas migrate diff生成版本化腳本。這樣既保證了開發(fā)效率又保留了生產(chǎn)環(huán)境的嚴謹。這個習慣堅持了大半年團隊成員從最開始質(zhì)疑“多出來的遷移文件是干嘛的”到后來主動在PR描述里附上遷移SQL的diff結(jié)果整個團隊的數(shù)據(jù)庫安全意識提升非常明顯。6.2 一個關(guān)于lint的小技巧atlas migrate lint在CI里建議始終使用--latest 1而不是對整個遷移目錄做全量檢查。全量lint不僅慢而且會把歷史遷移中的老問題重新翻出來導(dǎo)致CI一直紅失去了把關(guān)的意義。只檢查最近一個遷移文件才能確保每次PR的增量都在可控范圍內(nèi)。如果團隊有多個環(huán)境或多個業(yè)務(wù)庫還可以在atlas.hcl里通過env塊配置多條環(huán)境把不同的--dir和--dev-url固化下來省去每次敲一長串參數(shù)的麻煩。6.3 回不去手工遷移腳本了說實話使用Atlas之前我也曾覺得“數(shù)據(jù)庫遷移工具能有多大差別不就是執(zhí)行SQL嗎”。但真正習慣之后再讓我回到手寫遷移腳本的老路子我是真的回不去了。數(shù)據(jù)庫結(jié)構(gòu)是軟件系統(tǒng)里最難變的部分之一越是后期結(jié)構(gòu)變更的成本越高。把這個過程工程化、可視化、自動化帶來的收益不只是節(jié)省幾個小時而是讓整個團隊對數(shù)據(jù)庫變更有了掌控感。如果你也在為schema漂移、遷移腳本混亂、上線前臨時補DDL這些問題頭疼建議你花一個下午把Atlas跑通試試我相信你也會回來把它寫進自己的工作流里。