簡介《archery使用手冊(cè)》是一份針對(duì)Archery SQL審核查詢平臺(tái)的完整操作指南適合數(shù)據(jù)庫運(yùn)維、開發(fā)與測試人員快速上手MySQL審核及日常運(yùn)維。文檔首先解析SQL審核的執(zhí)行流程與自定義規(guī)則包括建表主鍵及注釋檢測、高危語句自動(dòng)駁回、釘釘通知并支持立即/定時(shí)執(zhí)行與回滾SQL生成隨后演示SQL分析、慢日志統(tǒng)計(jì)、通過執(zhí)行計(jì)劃獲取優(yōu)化建議等方法。在實(shí)例管理部分覆蓋binlog清理、會(huì)話終止、事務(wù)與鎖信息排查、賬號(hào)授權(quán)及動(dòng)態(tài)參數(shù)配置工具插件章節(jié)介紹PTArchiver數(shù)據(jù)歸檔、Binlog2SQL解析binlog生成回滾SQL、SchemaSync表結(jié)構(gòu)同步等實(shí)用功能并結(jié)合開發(fā)、測試環(huán)境的完整工單流程給出分步實(shí)踐。資源以單個(gè)doc文檔打包容量1.2MB內(nèi)容模塊劃分清晰便于按需查閱。已有1477人學(xué)習(xí)下載對(duì)正在落地SQL規(guī)范審核與數(shù)據(jù)庫自動(dòng)化運(yùn)維的團(tuán)隊(duì)具有直接參考價(jià)值。1. 從一次線上事故說起為什么數(shù)據(jù)平臺(tái)需要 Archery 這類 SQL 審核工具某團(tuán)隊(duì)曾經(jīng)在線上出過一次事故一條沒有 WHERE 條件的 UPDATE 被直接提交到了生產(chǎn)庫等發(fā)現(xiàn)時(shí)整張表的數(shù)據(jù)已經(jīng)被改成了同一個(gè)值最后用備份搶修了兩個(gè)多小時(shí)。事后復(fù)盤如果這條 SQL 在進(jìn)入生產(chǎn)前經(jīng)過一次自動(dòng)審核這個(gè)錯(cuò)誤完全可以在提交階段就被攔截。Archery 就是定位在這條防線上的一類平臺(tái)它對(duì) SQL 做語法解析和規(guī)則審核同時(shí)覆蓋 MySQL 實(shí)例的日常運(yùn)維把「開發(fā)提交 SQL → 審核 → 執(zhí)行 → 回滾」這條鏈路統(tǒng)一收口到一個(gè)系統(tǒng)里。這篇方案會(huì)按「需求 → 總體設(shè)計(jì) → 功能落地 → 實(shí)例管理與插件 → 排查避坑 → 驗(yàn)收答辯」的順序把這套工具拆成一份可以直接照著做的完整設(shè)計(jì)。適合正在搭建 SQL 審核流程的 DBA、運(yùn)維開發(fā)以及需要交數(shù)據(jù)庫方向課程設(shè)計(jì)或畢設(shè)的同學(xué)參考。2. 總體架構(gòu)設(shè)計(jì)SQL 審核、實(shí)例管理與工具插件的模塊劃分2.1 平臺(tái)定位一個(gè)入口覆蓋審核、查詢和運(yùn)維三類操作Archery 的定位不是普通的 SQL 執(zhí)行客戶端而是把 SQL 審核從「人工走查」變成「系統(tǒng)強(qiáng)制檢查」的中間層。它天然區(qū)分使用者和權(quán)限開發(fā)工程師提交 SQL 工單項(xiàng)目經(jīng)理或測試工程師做審核實(shí)例管理和高危操作默認(rèn)只有管理員賬號(hào)能操作。這種分層意味著在真實(shí)環(huán)境里它不是替代開發(fā)工具而是上線前最后一道閘門。從模塊上看Archery 主要由四個(gè)功能域構(gòu)成SQL 審核、SQL 優(yōu)化、實(shí)例管理、工具插件。SQL 審核負(fù)責(zé)工單全流程優(yōu)化負(fù)責(zé)執(zhí)行計(jì)劃分析和慢 SQL 統(tǒng)計(jì)實(shí)例管理負(fù)責(zé) binlog 清理、會(huì)話、事務(wù)、鎖、賬號(hào)和參數(shù)工具插件則把 PTArchiver、Binlog2SQL、SchemaSync 這些原本要手工命令行的工具變成界面化操作。以下表格給出各模塊與對(duì)應(yīng)職責(zé)模塊核心職責(zé)典型操作SQL 審核語法解析、規(guī)范檢查、高危語句駁回、回滾 SQL 生成提交工單、檢測、審核、執(zhí)行SQL 優(yōu)化執(zhí)行計(jì)劃分析、優(yōu)化建議、慢 SQL 統(tǒng)計(jì)分析 SQL、查看報(bào)告實(shí)例管理binlog 清理、會(huì)話終止、事務(wù)與鎖排查、賬號(hào)授權(quán)、參數(shù)修改查看進(jìn)程、終止會(huì)話、清 binlog工具插件數(shù)據(jù)歸檔、binlog 解析、表結(jié)構(gòu)同步PTArchiver 歸檔、Binlog2SQL 回滾、SchemaSync 比對(duì)在設(shè)計(jì)一個(gè)基于 Archery 的完整方案時(shí)通常的做法是先明確「哪類人走哪條流程」研發(fā)往開發(fā)環(huán)境提交工單走「研發(fā) → 項(xiàng)目經(jīng)理」兩級(jí)審核測試從 Git 取開發(fā)提交的 SQL 文件在測試環(huán)境發(fā)起工單由測試同事自己審核并執(zhí)行。這樣把流程固化到角色上比單純依賴口頭約定更不容易漏審。2.2 工單流程設(shè)計(jì)從 SQL 檢測到提交審核的狀態(tài)流轉(zhuǎn)Archery 的工單生命周期可以抽象為五個(gè)狀態(tài)待檢測、檢測通過、審核中、待執(zhí)行、已執(zhí)行。提交工單時(shí)操作人先填寫目標(biāo)實(shí)例、數(shù)據(jù)庫和 SQL 文件點(diǎn)擊「SQL 檢測」按鈕。檢測階段做的是語法解析與規(guī)則校驗(yàn)如果返回 error工單停留在待檢測狀態(tài)SQL 不會(huì)進(jìn)入任何執(zhí)行環(huán)節(jié)檢測通過后點(diǎn)擊「SQL 提交」工單進(jìn)入審核狀態(tài)。審核通過后的執(zhí)行環(huán)節(jié)值得重點(diǎn)設(shè)計(jì)Archery 同時(shí)支持「立即執(zhí)行」和「定時(shí)執(zhí)行」兩種方式。立即執(zhí)行適合低峰期的 DDL 或已確認(rèn)安全的變更定時(shí)執(zhí)行適合需要錯(cuò)峰上線的場景比如凌晨批量修改表結(jié)構(gòu)。兩種方式都會(huì)生成回滾 SQL 留底工單詳情里可以下載回滾 SQL也可以直接查看回滾內(nèi)容這相當(dāng)于給每次變更上了「后悔藥」。從實(shí)施角度看我一般會(huì)在方案里強(qiáng)制要求一條規(guī)則生產(chǎn)環(huán)境的高危語句必須經(jīng)過兩級(jí)審核并且必須生成回滾 SQL 后才能點(diǎn)執(zhí)行。這里的高危語句包括沒有 WHERE 條件的 UPDATE/ DELETE、DROP 操作、TRUNCATE 等。Archery 的高危語句自動(dòng)駁回機(jī)制正好承擔(dān)這部分檢查規(guī)則可以在后臺(tái)按實(shí)例粒度配置避免開發(fā)環(huán)境也套用生產(chǎn)那樣嚴(yán)格的紅線。2.3 通知鏈路釘釘通知與待辦事項(xiàng)的閉環(huán)審核流程很長如果不做通知工單會(huì)卡在某個(gè)審核人手里沒人知道。Archery 支持釘釘通知當(dāng)工單提交、審核通過、執(zhí)行完成或需要回滾時(shí)會(huì)向相關(guān)角色推送消息。設(shè)計(jì)上通知不是可選項(xiàng)而是流程閉環(huán)的一部分提交工單后通知審核人審核通過后通知提交人執(zhí)行完成后通知所有參與者。在部署方案里釘釘通知需要提前配置機(jī)器人 webhook并且要在 Archery 的設(shè)置中把審核人角色與待辦列表連接起來。項(xiàng)目經(jīng)理登錄后點(diǎn)擊右上角通知按鈕就能看到自己的待辦事項(xiàng)。這個(gè)設(shè)計(jì)解決了真實(shí)團(tuán)隊(duì)里「工單發(fā)起后無人響應(yīng)」的典型問題也讓每次審核動(dòng)作都有跡可循。3. 核心功能落地從 SQL 審核到優(yōu)化建議的完整實(shí)踐3.1 SQL 審核規(guī)則不只查語法還查規(guī)范Archery 的 SQL 審核不止做語法解析它還會(huì)按自定義規(guī)則檢查 SQL 是否符合數(shù)據(jù)庫規(guī)范。最常見的檢查項(xiàng)包括建表必須有主鍵、表必須有注釋、列必須有注釋、索引命名規(guī)范、禁止 SELECT *、禁止不帶 WHERE 的 UPDATE/DELETE 等。語法錯(cuò)誤直接被攔截規(guī)范問題會(huì)被標(biāo)記為警告或錯(cuò)誤由審核人在工單里看到。舉一個(gè)實(shí)際場景開發(fā)提交建表語句只寫了字段名和類型沒寫主鍵和注釋。Archery 檢測后會(huì)直接返回 error開發(fā)需要在原 SQL 上補(bǔ)充主鍵和列注釋重新提交檢測。這里的重點(diǎn)是「檢測是硬性的」error 狀態(tài)不允許提交審核這樣就避免了人工提醒容易漏掉的規(guī)范問題。從落地角度我一般會(huì)在方案的設(shè)計(jì)階段建立一份規(guī)則清單分為三類必選錯(cuò)誤建表無主鍵、高危語句、建議警告表名不帶前綴、缺少索引、信息提示影響行數(shù)過大。Archery 支持這種分級(jí)把不同的檢查項(xiàng)配置成 error 或 warn避免所有問題一刀切。3.2 SQL 優(yōu)化從 SELECT * 到執(zhí)行計(jì)劃分析Archery 的 SQL 優(yōu)化模塊能對(duì)指定 SQL 做執(zhí)行計(jì)劃分析并返回優(yōu)化建議。優(yōu)化建議的核心邏輯是先看訪問路徑再看返回字段。以下是一個(gè)典型示例-- 優(yōu)化前查詢所有字段且無法確認(rèn)是否走索引 SELECT * FROM baidd.emp WHERE enamedan_1;執(zhí)行計(jì)劃分析后通常會(huì)發(fā)現(xiàn)這里是全表掃描優(yōu)化建議會(huì)提示ename 字段是否建立索引、返回字段是否過多。改成明確字段列表后分析結(jié)果會(huì)變 OK-- 優(yōu)化后只返回業(yè)務(wù)需要的字段 SELECT ename, job, sal FROM baidd.emp WHERE enamedan_1;這里有一個(gè)容易被忽略的點(diǎn)優(yōu)化模塊返回的建議是「參考值」不是「最終答案」。真正上線前還需要確認(rèn) ename 字段的索引是否已經(jīng)存在以及數(shù)據(jù)分布情況。如果存在索引但選擇性不高優(yōu)化器可能仍然走全表掃描。Archery 的價(jià)值在于把執(zhí)行計(jì)劃可視化讓人能快速看到訪問路徑而不是直接替開發(fā)做決定。3.3 慢 SQL 統(tǒng)計(jì)與優(yōu)化閉環(huán)慢 SQL 是數(shù)據(jù)庫性能問題的第一來源。Archery 能展示慢 SQL 及其統(tǒng)計(jì)信息包括執(zhí)行次數(shù)、平均耗時(shí)、最大耗時(shí)等。設(shè)計(jì)思路是把慢 SQL 作為優(yōu)化入口點(diǎn)擊某條慢 SQL 后直接調(diào)用 SQL 優(yōu)化模塊生成執(zhí)行計(jì)劃和優(yōu)化建議形成「發(fā)現(xiàn)慢 SQL → 分析 → 優(yōu)化 → 驗(yàn)證」的閉環(huán)。在實(shí)施時(shí)我會(huì)在部署方案里加一條約定每個(gè)實(shí)例每周同步一次慢日志DBA 從慢 SQL 列表里挑執(zhí)行次數(shù)最多、耗時(shí)最長的 Top 10 做分析。優(yōu)化完成后下周再回看統(tǒng)計(jì)數(shù)據(jù)確認(rèn)確實(shí)降下來了。這套閉環(huán)同時(shí)覆蓋開發(fā)自測和生產(chǎn)排查比單次優(yōu)化更有說服力。4. 實(shí)例管理實(shí)戰(zhàn)會(huì)話、事務(wù)、鎖與賬號(hào)的運(yùn)維閉環(huán)4.1 會(huì)話管理定位阻塞 SQL 并終止實(shí)例管理是 Archery 最貼近 DBA 日常工作的部分。會(huì)話管理模塊可以看到當(dāng)前正在執(zhí)行的 SQL按數(shù)據(jù)庫實(shí)例和 command 類型過濾默認(rèn)只顯示 query 類型需要查看所有進(jìn)程時(shí)切換為 All。這里有一個(gè)細(xì)節(jié)查看進(jìn)程列表時(shí)勾選「完整 INFO」才能顯示完整 SQL 文本否則長 SQL 會(huì)被截?cái)嗯挪闀r(shí)很容易漏掉關(guān)鍵信息。定位到某個(gè) SQL 導(dǎo)致阻塞后可以直接點(diǎn)擊「終止會(huì)話」按鈕。這個(gè)功能在生產(chǎn)環(huán)境下要謹(jǐn)慎使用終止前務(wù)必確認(rèn)該會(huì)話不是批量導(dǎo)入或關(guān)鍵事務(wù)。我的做法是先看完整 INFO 確認(rèn) SQL 內(nèi)容再確認(rèn)發(fā)起賬號(hào)角色最后才終止。終止動(dòng)作本身可以在 Archery 的操作記錄里留痕方便事后追溯。4.2 事務(wù)與鎖信息用 trx_mysql_thread_id 串聯(lián)定位鎖等待是數(shù)據(jù)庫運(yùn)維里最常見的疑難問題Archery 把事務(wù)信息和鎖信息做成可視化界面定位路徑比命令行清晰得多。事務(wù)信息里能看到當(dāng)前運(yùn)行事務(wù)其中trx_mysql_thread_id對(duì)應(yīng)會(huì)話管理里的 THREAD ID。想殺掉事務(wù)時(shí)先按這個(gè) ID 在進(jìn)程狀態(tài)里搜索找到后終止會(huì)話即可。鎖信息模塊的典型用法是模擬鎖等待。以下是在兩個(gè)獨(dú)立連接里執(zhí)行的 SQL-- 會(huì)話 A開啟事務(wù)并更新主鍵為 2 的記錄不提交 BEGIN; UPDATE baidd.t2 SET enamebaidd WHERE id2; -- 會(huì)話 B對(duì)同一條記錄更新會(huì)被阻塞 UPDATE baidd.t2 SET enamedan WHERE id2;會(huì)話 B 阻塞后打開 Archery 的鎖信息能看到等待事務(wù)的 SQL即被阻塞的 SQL也能看到阻塞方的線程 ID。根據(jù)阻塞方線程 ID 去進(jìn)程狀態(tài)里找到對(duì)應(yīng)會(huì)話并終止鎖就釋放了。這套操作適用于日常排障和答辯演示因?yàn)樗暾采w了「模擬問題 → 定位問題 → 解決問題」三個(gè)環(huán)節(jié)。4.3 賬號(hào)管理與參數(shù)配置把高危操作收進(jìn)界面賬號(hào)管理模塊解決的是「創(chuàng)建賬號(hào)、授權(quán)、改密、刪除」的圖形化操作問題。建完賬號(hào)后可以為其授權(quán)例如賦予增刪改查和修改表結(jié)構(gòu)的權(quán)限。設(shè)計(jì)上有一條紅線權(quán)限要按最小化原則分配普通應(yīng)用賬號(hào)只給 SELECT/INSERT/UPDATE/DELETE不給 DROP 和 GRANT OPTION。Archery 的賬號(hào)管理讓這條紅線可以通過界面落實(shí)而不是靠 DBA 手工敲命令。參數(shù)配置模塊可以修改實(shí)例動(dòng)態(tài)參數(shù)并記錄修改歷史。改參數(shù)本身是高危操作沒有留痕就會(huì)變成黑匣子。Archery 會(huì)把每一次參數(shù)變更記錄在案這樣一旦實(shí)例行為異?？梢韵然乜磪?shù)變更歷史。4.4 binlog 清理與磁盤空間釋放實(shí)例列表里提供 binlog 清理功能用于釋放磁盤空間。操作邏輯需要注意在實(shí)例列表選中某個(gè) binlog 后該 binlog 之前的所有 binlog 都會(huì)一并刪除。也就是說選中的位置決定了保留邊界。清理前必須確認(rèn)兩個(gè)問題一是目標(biāo)實(shí)例是否被主從復(fù)制依賴二是保留的文件是否足夠完成增量恢復(fù)。通常在磁盤空間不足時(shí)先按時(shí)間排序確認(rèn)最老的 binlog 已經(jīng)不再被復(fù)制位點(diǎn)引用再執(zhí)行清理。5. 高頻問題排查與避坑審核駁回、回滾失敗、鎖等待的典型翻車點(diǎn)5.1 審核階段的翻車點(diǎn)檢測 error 但開發(fā)認(rèn)為沒問題現(xiàn)象開發(fā)提交 SQL 后點(diǎn)擊檢測返回 error。開發(fā)對(duì)照 SQL 反復(fù)看覺得語法是對(duì)的也沒有高危操作不理解為什么被攔。打開工單詳情發(fā)現(xiàn) error 信息提示的是「建表缺少主鍵」或「表名不符合命名規(guī)范」。原因Archery 的檢測包含語法解析和規(guī)則校驗(yàn)兩層。語法正確不代表規(guī)范正確規(guī)則庫里配置了主鍵、注釋、命名等硬性要求缺任何一項(xiàng)都會(huì)判 error。解決有兩種處理方式。第一種是按 error 提示修改 SQL補(bǔ)上主鍵和注釋后重新檢測第二種是如果確認(rèn)這條 SQL 的場景不需要某條規(guī)則例如臨時(shí)表由管理員在規(guī)則配置里將該項(xiàng)調(diào)整為 warn。我一般會(huì)在方案里建議規(guī)范類規(guī)則保持 error 不放松避免開發(fā)養(yǎng)成「跳過規(guī)范」的習(xí)慣。5.2 回滾階段的翻車點(diǎn)DDL 無法回滾與 Binlog2SQL 的邊界現(xiàn)象執(zhí)行完一條 DROP TABLE 后發(fā)現(xiàn)刪錯(cuò)了點(diǎn)「下載回滾 SQL」回滾內(nèi)容為空?；蚴褂?Binlog2SQL 生成回滾 SQL 時(shí)提示解析失敗。原因Archery 的回滾 SQL 依賴 binlog 解析。DML 操作INSERT/UPDATE/DELETE可以通過反向解析生成回滾語句但 DDL 操作在 binlog 里沒有足夠的行級(jí)前后映像無法生成對(duì)應(yīng)的反向 DDL。Binlog2SQL 明確不支持回滾 DDL僅能回滾 DML。解決在使用前就要建立預(yù)期DDL 變更必須靠備份兜底不能依賴 Archery 生成回滾。對(duì)于 Binlog2SQL 解析失敗還需要檢查 binlog 格式必須設(shè)置為 ROW 格式才能解析出完整的前后映像。另外解析時(shí)要指定正確的 binlog 文件名和起始位置比如master-bin.000009從857到1183位置越精確生成的 SQL 越干凈。5.3 運(yùn)維操作的翻車點(diǎn)清理 binlog 和終止會(huì)話誤傷現(xiàn)象清理 binlog 后主從復(fù)制中斷?；蛘呓K止會(huì)話時(shí)殺掉了一個(gè)正在執(zhí)行長事務(wù)的連接導(dǎo)致應(yīng)用端報(bào)錯(cuò)。原因binlog 清理選中了當(dāng)前正在使用的文件或清理到主從還沒復(fù)制的位點(diǎn)會(huì)話終止時(shí)沒有先查看完整 SQL 和事務(wù)信息誤殺了關(guān)鍵連接。解決清理 binlog 前先查看復(fù)制狀態(tài)確認(rèn)從庫已經(jīng)拉取的位點(diǎn)再選擇要保留的 binlog 文件。終止會(huì)話前勾選「完整 INFO」查看 SQL 完整文本并到事務(wù)信息里確認(rèn)該連接是否有未提交事務(wù)。我的習(xí)慣是先查鎖信息定位阻塞源再從進(jìn)程狀態(tài)里確認(rèn)進(jìn)程身份最后才操作終止三步缺一不可。5.4 SchemaSync 的認(rèn)知誤區(qū)只比表結(jié)構(gòu)不比數(shù)據(jù)現(xiàn)象用 SchemaSync 做開發(fā)庫和測試庫同步后發(fā)現(xiàn)兩個(gè)庫的數(shù)據(jù)量不一致誤以為同步工具出問題。反復(fù)檢查配置工單執(zhí)行結(jié)果都是成功。原因SchemaSync 的定位是讀取源 DB 和目標(biāo) DB 的 schema自動(dòng)生成同步更新和回滾的 SQL。它只比對(duì)表結(jié)構(gòu)建表語句、字段、索引、約束不涉及數(shù)據(jù)層面的任何比對(duì)。解決方案里要明確區(qū)分兩類同步工具表結(jié)構(gòu)同步用 SchemaSync數(shù)據(jù)同步用 PTArchiver 或 Binlog2SQL 數(shù)據(jù)導(dǎo)出導(dǎo)入。SchemaSync 適合「兩個(gè)環(huán)境表結(jié)構(gòu)漂移」的場景例如目標(biāo)庫缺少字段或索引時(shí)它會(huì)生成相對(duì)于源庫應(yīng)該執(zhí)行的 DDL 操作同時(shí)生成回滾 SQL。比對(duì)完確認(rèn)無誤后再執(zhí)行避免兩邊越漂越遠(yuǎn)。6. 驗(yàn)收與答辯用一條完整工單流證明方案可行驗(yàn)收這套方案不能只展示界面截圖要搭一套最小驗(yàn)證環(huán)境按真實(shí)流程走一遍。我會(huì)準(zhǔn)備兩個(gè) MySQL 實(shí)例模擬開發(fā)庫和測試庫再準(zhǔn)備一張無主鍵的建表 SQL 用于演示審核駁回。驗(yàn)收清單按五個(gè)場景設(shè)計(jì)第一提交一條缺主鍵的建表 SQL確認(rèn)檢測返回 error 且無法提交第二提交一條合規(guī) SQL走完審核、立即執(zhí)行、生成回滾 SQL第三用兩條連接模擬鎖等待從鎖信息定位阻塞方并終止第四打開 binlog 解析確認(rèn)能生成回滾 SQL第五用 SchemaSync 比對(duì)兩個(gè)庫確認(rèn)只生成 DDL 同步語句。每個(gè)場景都記錄截圖和結(jié)果答辯時(shí)直接展示。答辯的技巧是先把最有沖擊力的環(huán)節(jié)放前面先演示「高危語句自動(dòng)駁回」再演示「鎖等待定位與終止」這兩個(gè)場景最能體現(xiàn)平臺(tái)價(jià)值。然后講審核流程和自動(dòng)化插件評(píng)審一般會(huì)追問回滾失敗的場景這時(shí)就把 DDL 不可回滾的邊界講清楚說明不是工具缺陷而是 binlog 機(jī)制決定的。曾經(jīng)有一次演示前發(fā)現(xiàn)實(shí)例連不上排查了半天才知道是 binlog 沒開啟導(dǎo)致回滾 SQL 生成不了。從那以后我每次演示前都會(huì)強(qiáng)制走一遍冒煙測試確認(rèn) binlog 開啟、確認(rèn)實(shí)例可連接、跑通一條完整工單大概五分鐘就能避免現(xiàn)場翻車。這套流程也建議你直接拿去用希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取