入職這些年我發(fā)現(xiàn)自己干得最多的活不是寫業(yè)務代碼也不是搭架構而是跟一堆數(shù)據(jù)庫常用腳本打交道。無論是幫業(yè)務部門查一條慢SQL還是半夜被叫起來看主從延遲手里沒幾個趁手的腳本真就寸步難行。今天這篇不整虛的把我實際工作中反復在用、踩過坑之后修正過的腳本整理出來按場景分類講清楚每個腳本為什么這么寫、參數(shù)怎么調、遇到什么問題怎么改都一并交代。適合剛接觸數(shù)據(jù)庫運維的開發(fā)者也適合想把手頭腳本整理得更規(guī)范的DBA。1. 信息查詢與元數(shù)據(jù)腳本先把家底盤清楚1.1 三分鐘摸清實例整體狀況接手一臺新的數(shù)據(jù)庫服務器第一件事不是急著優(yōu)化而是先搞清楚這臺實例到底什么配置、什么負載、什么水位。我習慣先跑一套體檢三連-- 查看實例版本、運行時長、字符集等基礎信息 SELECT VERSION() AS version, NOW() AS current_time, hostname AS host_name, port AS port, character_set_server AS charset, collation_server AS collation; -- 查看關鍵運行狀態(tài)值重點看連接數(shù)和慢查詢 SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Threads_running; SHOW GLOBAL STATUS LIKE Slow_queries; SHOW GLOBAL STATUS LIKE Uptime; -- 查看InnoDB buffer pool命中率相關指標 SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;這幾個腳本看著簡單但信息密度很高。版本和端口就不說了Threads_connected和Threads_running這兩個值一定要配合看前者代表當前建立的連接數(shù)后者代表真正在執(zhí)行SQL的線程數(shù)。如果連接數(shù)飆到幾百但Threads_running一直不高說明大部分連接是閑置連接問題多半出在應用側連接池配置上而不是數(shù)據(jù)庫本身。InnoDB buffer pool命中率有個經(jīng)驗公式1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)這個值常年低于99%說明內(nèi)存配置或查詢模式有問題光靠加內(nèi)存未必管用可能得從SQL層面找原因。1.2 快速定位大表與膨脹空間剛接手一個庫業(yè)務方問我哪些表最大、哪些表膨脹得厲害我從來不看information_schema因為那個統(tǒng)計信息在數(shù)據(jù)量大的時候本身就不準掃描也慢。直接用系統(tǒng)表查快得多-- 查看指定庫中各表的行數(shù)、數(shù)據(jù)大小、索引大小MySQL 8.0 SELECT table_name, table_rows, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb, ROUND((data_length index_length) / 1024 / 1024, 2) AS total_mb FROM information_schema.tables WHERE table_schema your_db ORDER BY total_mb DESC LIMIT 20;這里有個細節(jié)必須提醒table_rows是估算值InnoDB引擎下誤差可能很大尤其頻繁增刪的表。真要精確行數(shù)還是得SELECT COUNT(*)但大表別在生產(chǎn)上直接跑低峰期再操作。另外我還會加一個查詢看哪些表的數(shù)據(jù)量和索引量比例失調。曾遇到一張表數(shù)據(jù)才200MB索引卻占了1.5GB查下來是建了一堆冗余的聯(lián)合索引刪掉三個索引后空間直接釋放寫入性能也提升了。索引不是越多越好這個后面專門講。1.3 找出從未被使用的索引索引是有維護成本的每次寫入都要更新索引結構。很多系統(tǒng)上線久了當初拍腦袋建的索引根本沒人用白白拖累寫入性能。查索引使用情況MySQL有現(xiàn)成的統(tǒng)計表-- 查看索引使用統(tǒng)計需開啟performance_schemaMySQL 5.7 SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_STAR, COUNT_READ, COUNT_WRITE FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA your_db AND INDEX_NAME IS NOT NULL ORDER BY COUNT_READ ASC LIMIT 20;COUNT_READ長期為0的索引基本就是死索引。但刪之前務必確認兩點第一查詢計劃里是否真的沒用到有些統(tǒng)計值低但偶爾高峰用到的索引不能動第二有沒有唯一性約束依賴這個索引。我習慣把候選索引先標記為INVISIBLEMySQL 8.0支持觀察一周確認沒有報錯再真正DROP這個操作可以說非常穩(wěn)妥。2. 備份與恢復腳本平時用不上出事保命2.1 邏輯備份腳本的正確姿勢說到備份很多人第一反應就是mysqldump一把梭。但我見過太多因為參數(shù)沒加對導致備份恢復失敗的案例。我最常用的一套邏輯備份腳本長這樣#!/bin/bash # 按庫備份保留最近7天帶時間戳 BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d_%H%M%S) DB_USERbackup_user DB_PASSyour_password DB_LISTdb1 db2 db3 for DB in $DB_LIST; do mysqldump \ --single-transaction \ --routines \ --triggers \ --events \ --set-gtid-purgedOFF \ -u$DB_USER -p$DB_PASS $DB \ | gzip $BACKUP_DIR/${DB}_${DATE}.sql.gz done # 清理7天前的備份 find $BACKUP_DIR -name *.sql.gz -mtime 7 -delete這幾個參數(shù)每個都有講究--single-transaction不加這個InnoDB表備份時會對全表加鎖線上業(yè)務直接卡住。加上后基于MVCC一致性快照不鎖表。--routines --triggers --events不加這三個存儲過程、觸發(fā)器、事件調度器全部丟失。很多人恢復后發(fā)現(xiàn)跑批任務不見了就是栽在這。--set-gtid-purgedOFFGTID模式下的老坑。不關掉這個問題備份文件里帶著GTID信息恢復到新實例時會因為事務ID沖突直接報錯。注意--single-transaction對MyISAM表無效MyISAM依舊會鎖表。如果庫里還有MyISAM表建議要么遷移到InnoDB要么備份安排在業(yè)務低谷期執(zhí)行。2.2 更穩(wěn)的物理備份xtrabackupmysqldump在數(shù)據(jù)量超過幾十GB時就不太合適了備份慢、恢復更慢而且邏輯備份恢復時重放SQL耗時很長。這時候我直接用物理備份工具做全量增量備份#!/bin/bash # 全量物理備份腳本 BACKUP_BASE/data/backup/xtra DATE$(date %Y%m%d) FULL_DIR$BACKUP_BASE/full_$DATE xtrabackup \ --backup \ --target-dir$FULL_DIR \ --userbackup_user \ --passwordyour_password \ --parallel4 \ --compress # 備份完成后再做一步prepare保證備份集可用于恢復 xtrabackup --prepare --target-dir$FULL_DIR很多人備份完直接拷走恢復的時候才發(fā)現(xiàn)xtrabackup --prepare這步?jīng)]做數(shù)據(jù)文件處于不一致狀態(tài)根本起不來。--prepare的原理類似InnoDB崩潰恢復把redo log回放到數(shù)據(jù)文件里這步必須執(zhí)行且prepare后的備份集不能再增量備份。物理備份的恢復動作也比邏輯備份簡單直接把備份集解壓拷回數(shù)據(jù)目錄改好屬主權限啟動實例即可。我實測過100GB的數(shù)據(jù)xtrabackup備份加恢復全程不到半小時mysqldump可能要折騰兩個小時以上。2.3 備份不等于高枕無憂恢復演練腳本這是我最想強調的一點不做恢復演練的備份等于沒有備份。遇到過不止一次平時備份任務天天跑真到恢復那天發(fā)現(xiàn)備份文件損壞、參數(shù)不兼容、磁盤空間不夠全抓瞎。我現(xiàn)在的習慣是每月至少做一次完整的恢復演練腳本固定如下#!/bin/bash # 恢復到臨時實例并校驗數(shù)據(jù)完整性 RESTORE_DIR/data/restore_test PORT3307 DATA_DIR$RESTORE_DIR/data # 1. 解壓最新全量備份 LATEST_BACKUP$(ls -t /data/backup/mysql/*.sql.gz | head -1) gunzip -c $LATEST_BACKUP $RESTORE_DIR/restore.sql # 2. 直接初始化一個新實例 mysqld --no-defaults \ --datadir$DATA_DIR \ --port$PORT \ --socket$RESTORE_DIR/mysql.sock \ --initialize-insecure # 3. 導入數(shù)據(jù) mysql --socket$RESTORE_DIR/mysql.sock -uroot $RESTORE_DIR/restore.sql # 4. 關鍵表行數(shù)校驗 mysql --socket$RESTORE_DIR/mysql.sock -uroot -e SELECT COUNT(*) FROM your_db.key_table;恢復演練不只是驗證備份文件可用還能順便驗證備份腳本里的參數(shù)變化是否兼容當前版本。比如之前從MySQL 5.7升級到8.0后老的備份恢復腳本就因為sql_mode差異跑掛過演練第一個發(fā)現(xiàn)問題。3. 巡檢與監(jiān)控腳本日常保健勝過臨時搶救3.1 連接與線程狀態(tài)實時巡檢數(shù)據(jù)庫出問題十有八九先反應在連接和線程上。我寫了一個一鍵巡檢腳本每分鐘跑一次把異常情況直接打到日志里-- 檢查當前連接數(shù)是否超過閾值這里是200 SHOW STATUS WHERE variable_name Threads_connected; -- 查看當前所有非Sleep狀態(tài)的SQL SELECT id, user, host, db, command, time, state, LEFT(info, 120) AS sql_text FROM information_schema.processlist WHERE command ! Sleep ORDER BY time DESC; -- 查看處于鎖等待的會話 SELECT * FROM information_schema.innodb_trx WHERE trx_state LOCK WAIT;information_schema.processlist這個表是排查問題的第一現(xiàn)場?？吹絫ime特別長的Query別急著KILL先看state字段如果是Sending data可能真的是大查詢?nèi)绻荳aiting for table metadata lock多半是DDL和DML打架了如果是Waiting for handler commit可能是磁盤刷盤太慢。有一次線上業(yè)務卡死我用這個腳本查出來一個time2400的ALTER TABLE在等元數(shù)據(jù)鎖后面堵了一串查詢。找到根源后把那個一直沒提交的長事務KILL掉業(yè)務立刻恢復。沒有這個巡檢思路光看連接數(shù)飚高是定位不到根因的。3.2 慢查詢與錯誤日志分析腳本慢查詢?nèi)罩疽欢ㄒ_但開了不分析等于白開。我習慣把慢查詢?nèi)罩竞湾e誤日志都統(tǒng)一到一個目錄然后用腳本做每日分析#!/bin/bash # 每日慢查詢統(tǒng)計輸出Top10耗時SQL SLOW_LOG/var/log/mysql/slow-query.log TODAY$(date %Y%m%d) # 統(tǒng)計當天慢查詢總數(shù) TOTAL$(grep -c Time: $SLOW_LOG || true) echo $TODAY slow query total: $TOTAL # 提取慢查詢中的SQL文本統(tǒng)計出現(xiàn)頻率 grep -A2 Query_time $SLOW_LOG | \ grep ^SELECT\|^UPDATE\|^DELETE\|^INSERT | \ sort | uniq -c | sort -rn | head -20這個腳本的思路是先看量再看質。慢查詢多不一定是壞事要看是否集中在少數(shù)幾條SQL上。如果每天都有一批SQL穩(wěn)定出現(xiàn)在慢查詢列表且執(zhí)行計劃沒變說明SQL本身有問題需要從索引和改寫兩個方向處理。有個經(jīng)驗分享慢查詢?nèi)罩纠锏腞ows_examined遠比Query_time重要。Rows_examined幾十萬但只返回幾行說明掃描了大量數(shù)據(jù)索引沒走對或者索引選擇性差。優(yōu)化這類SQL收益大且確定。3.3 磁盤與表空間水位監(jiān)控數(shù)據(jù)庫的磁盤滿了是真的會寫不進去任何數(shù)據(jù)的而且一旦滿盤恢復起來極其痛苦。所以磁盤監(jiān)控我寧可多寫幾個腳本也不愿意半夜被叫起來。#!/bin/bash # 磁盤與關鍵目錄監(jiān)控超過80%告警 THRESHOLD80 ALERT_FILE/data/monitor/disk_alert.log df -h | grep -E ^/dev/(sd|vd) | while read line; do USAGE$(echo $line | awk {print $5} | sed s/%//) MOUNT_POINT$(echo $line | awk {print $6}) if [ $USAGE -ge $THRESHOLD ]; then echo $(date %Y-%m-%d %H:%M:%S) WARN: $MOUNT_POINT usage $USAGE% $ALERT_FILE fi done # InnoDB表空間大小分布Top10 mysql -u monitor_user -p$PASSWORD -e SELECT table_schema, SUM(data_length index_length) / 1024 / 1024 / 1024 AS total_gb FROM information_schema.tables GROUP BY table_schema ORDER BY total_gb DESC; $ALERT_FILE告警閾值80%是我個人的習慣不一定適合所有人。如果業(yè)務有大量臨時排序或日志寫入建議把閾值調到70%給臨時文件留出緩沖。數(shù)據(jù)目錄和日志目錄最好分開監(jiān)控binlog目錄漲速快一天幾個GB很正常單獨看才不會忽略。另外提醒一個容易忽略的點監(jiān)控腳本本身也要做清理監(jiān)控日志文件無限增長會把磁盤反過來寫滿。logrotate配一下或者用find ... -mtime 30 -delete做輪轉。4. 性能優(yōu)化輔助腳本找到瓶頸、對癥下藥4.1 直擊性能瓶頸的SQL定位線上系統(tǒng)變慢最忌諱的就是憑感覺調參數(shù)。我的做法是先把壓在庫上的SQL揪出來分析執(zhí)行計劃再決定怎么改。下面這個腳本是我最常用的SQL分析三板斧-- 1. 開啟執(zhí)行計劃分析 EXPLAIN ANALYZE SELECT order_id, user_id, amount FROM orders WHERE user_id 12345 AND status PAID AND create_time 2024-01-01 ORDER BY create_time DESC LIMIT 20;EXPLAIN ANALYZE是MySQL 8.0才有的它不只是給出執(zhí)行計劃還會真實執(zhí)行SQL并返回每一步的耗時和掃描行數(shù)。對于一條慢SQL先用它看瓶頸在哪一步是索引掃描行數(shù)太多還是排序耗時太長還是回表次數(shù)太多。我遇到過一條SQL加了個索引之后從2秒提升到50毫秒以為是索引生效了但用EXPLAIN ANALYZE一查發(fā)現(xiàn)真正的問題是ORDER BY create_time DESC觸發(fā)了filesort。后來把索引改成(user_id, status, create_time)讓索引天然有序徹底消除filesort才真正解決問題。沒有EXPLAIN ANALYZE我只能看到加索引變快了看不到完整的優(yōu)化鏈路。4.2 大表碎片整理腳本InnoDB表在頻繁更新和刪除后會產(chǎn)生大量碎片。表現(xiàn)就是表的數(shù)據(jù)量沒怎么漲但物理文件越來越大全表掃描越來越慢。整理碎片的方法很直接-- 查看表碎片率 SELECT table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(data_free / 1024 / 1024, 2) AS fragmented_mb, ROUND(data_free / data_length * 100, 2) AS fragment_pct FROM information_schema.tables WHERE table_schema your_db AND data_free 100 * 1024 * 1024 -- 只列出碎片超過100MB的表 ORDER BY fragment_pct DESC LIMIT 20;對于碎片率高的表執(zhí)行ALTER TABLE table_name ENGINEInnoDB即可重建表、回收碎片空間。但這里有幾個必須注意的坑這個操作會鎖表盡管MySQL 5.6是Online DDL但數(shù)據(jù)量巨大的表仍可能引發(fā)長時間元數(shù)據(jù)鎖務必安排在維護窗口。整理碎片前先看磁盤剩余空間重建表需要約等于原表大小的額外空間。MySQL 8.0之后這個動作可以用ALTER TABLE ... FORCE代替效果更明確。有個取巧的辦法如果表上有定期歸檔任務歸檔后碎片自然產(chǎn)生建議把碎片整理加入每月的自動任務比一次性整理大表風險低得多。4.3 關鍵參數(shù)調優(yōu)自查腳本網(wǎng)上到處是MySQL優(yōu)化必須改這10個參數(shù)的文章但盲目調參翻車的案例我見得太多了。參數(shù)調優(yōu)最靠譜的依據(jù)是自己的監(jiān)控數(shù)據(jù)我寫了一個自查腳本輸出當前實際運行情況對應的參數(shù)建議-- 查看緩存命中率的真實數(shù)據(jù) SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read%; SHOW GLOBAL STATUS LIKE Innodb_row_lock_current_waits; SHOW GLOBAL STATUS LIKE Innodb_row_lock_time; -- 查看當前實際生效的參數(shù)值 SHOW VARIABLES LIKE innodb_buffer_pool_size; SHOW VARIABLES LIKE innodb_flush_log_at_trx_commit; SHOW VARIABLES LIKE max_connections; SHOW VARIABLES LIKE transaction_isolation;這里我最想展開講的是innodb_flush_log_at_trx_commit。這個參數(shù)只有三個取值0、1、2很多優(yōu)化文章建議改成0或2來提升性能但代價是事務提交時可能丟失最多1秒的日志這在金融、訂單等場景是絕對不可接受的。我的原則是核心業(yè)務必須保持1非核心報表庫可以考慮20絕不推薦。調參之前先問自己三個問題改這個參數(shù)要解決的問題是什么改完如何驗證確實解決了回滾方案是什么答不上來任何一個就不要動。5. 常見問題與排查技巧實錄5.1 連接數(shù)打滿排查現(xiàn)象Threads_connected達到max_connections上限新連接直接報Too many connections。排查順序先看Threads_running如果這個值不高說明大量連接是Sleep狀態(tài)應用連接池沒釋放。查information_schema.processlist看Sleep連接來自哪些host定位是哪個應用?？磻眠B接池配置maxPoolSize是不是設置得過大、idleTimeout是不是沒生效。如果是突發(fā)流量導致臨時調大max_connections能救急但根治要看應用側連接復用。我以前遇到過一個案例某服務每執(zhí)行一次查詢就新建連接用完不歸還連接池形同虛設。排查完發(fā)現(xiàn)是應用框架的配置項被誤改了maximumPoolSize寫成了1000而數(shù)據(jù)庫max_connections才500必然打滿。腳本只是定位工具根因分析還得靠對業(yè)務側的理解。5.2 鎖等待問題處理現(xiàn)象業(yè)務報錯里出現(xiàn)Lock wait timeout exceeded或者Deadlock found。處理思路-- 查看當前所有事務 SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.innodb_trx; -- 查看鎖等待關系 SELECT waiting_trx_id, waiting_thread, waiting_query, blocking_trx_id, blocking_thread, blocking_query FROM sys.innodb_lock_waits;sys.innodb_lock_waits是MySQL 5.7及以上版本提供的視圖直接列出誰在等鎖、誰持有鎖。優(yōu)先處理持有鎖的那個長事務如果業(yè)務上允許直接把它KILL掉。但KILL是治標根源通常在兩條事務沒及時提交應用層忘記commit、或者事務范圍過大一個事務里做了太多查詢和計算。死鎖的話MySQL會自動回滾其中一個事務應用側要有重試機制。這個事情別依賴數(shù)據(jù)庫幫你想辦法應用層做重試才是正解。5.3 主從延遲排查主從延遲是另一種常見的數(shù)據(jù)庫沒事但業(yè)務很慢的場景。查主從狀態(tài)用下面的腳本SHOW SLAVE STATUS\G -- 關鍵字段 -- Seconds_Behind_Master: 從庫落后主庫的秒數(shù) -- Slave_IO_Running: IO線程是否正常必須是Yes -- Slave_SQL_Running: SQL線程是否正常必須是Yes -- Last_IO_Error / Last_SQL_Error: 有值必查這是報錯現(xiàn)場Seconds_Behind_Master為0不代表沒延遲它只是估算值主庫大事務執(zhí)行期間這個值可能顯示0因為從庫根本沒追上主庫當前的binlog位置。更可靠的判斷標準是對比主從的Master_Log_File/Read_Master_Log_Pos與從庫執(zhí)行到的Relay_Master_Log_File/Exec_Master_Log_Pos。主從延遲最常見的原因按優(yōu)先級排列大事務一條SQL更新幾百萬行、從庫硬件性能弱、從庫上跑著分析查詢搶資源、DDL在從庫被打斷。解決方向也很明確把大事務拆小、控制從庫上的分析負載、保障主從硬件規(guī)格一致。5.4 快速定位性能拐點最后一個腳本也是我調優(yōu)時候最重要的參考依據(jù)通過performance_schema拿到真實的等待事件分布。-- 等待事件Top10MySQL 5.7 SELECT EVENT_NAME, COUNT_STAR, ROUND(SUM_TIMER_WAIT / 1000000000, 2) AS wait_seconds FROM performance_schema.events_waits_summary_global_by_event_name WHERE SUM_TIMER_WAIT 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;看到wait_seconds最大的等待事件基本就鎖定了瓶頸所在。io/sql/file類等待大說明磁盤I/O扛不住wait/synch/mutex類等待大說明并發(fā)爭用嚴重可能需要拆分熱點或升級配置idle類占比高說明數(shù)據(jù)庫很閑問題大概率在應用側。這個腳本的價值在于把感覺慢變成數(shù)據(jù)說話。我優(yōu)化完某個參數(shù)或SQL之后都會跑一次這個查詢做前后對比用數(shù)據(jù)確認優(yōu)化是否真的有效而不是感覺似乎快了一點。6. 數(shù)據(jù)訂正與批量操作腳本小心駛得萬年船6.1 大批量數(shù)據(jù)更新的安全寫法日常工作中總有改數(shù)據(jù)的需求比如訂正一條狀態(tài)、批量覆蓋一個字段。這類操作看著簡單翻車概率卻極高尤其是幾百萬行的大表直接UPDATE鎖表能把整個業(yè)務拖死。我現(xiàn)場更的每條大語句都遵循同一個模式-- 分批更新每批1000條循環(huán)執(zhí)行 DELIMITER $$ CREATE PROCEDURE batch_update() BEGIN DECLARE v_count INT DEFAULT 1; WHILE v_count 0 DO UPDATE orders SET status ARCHIVED WHERE status OLD AND id IN ( SELECT id FROM ( SELECT id FROM orders WHERE status OLD LIMIT 1000 ) tmp ); SET v_count ROW_COUNT(); -- 每批之間歇一下給其他事務留機會 DO SLEEP(0.1); END WHILE; END$$ DELIMITER ; CALL batch_update();外層套一層SELECT id FROM (...)子查詢是因為MySQL不允許在UPDATE的子查詢里直接查同一張表。SLEEP(0.1)是為了讓出部分鎖資源避免長事務囤積大量行鎖。這種方式雖然慢但安全度完全不同實測200萬行也就跑十幾分鐘比起鎖死核心表讓整個業(yè)務癱瘓這點時間完全值得。6.2 誤更新后的快速恢復方案批量更新的另一面是萬一條件寫錯了怎么辦。我給自己留的后手是定期維護一份關鍵表的變更前快照-- 大操作前先備份目標表到備份表 CREATE TABLE orders_backup_20240101 AS SELECT * FROM orders; -- 如果操作出錯用備份表恢復 -- 先刪掉錯誤數(shù)據(jù)再按主鍵從備份表恢復 DELETE FROM orders; INSERT INTO orders SELECT * FROM orders_backup_20240101;這個方案雖然簡單粗暴但在關鍵時刻能救命。注意幾點備份表本身也占空間大表要確認磁盤夠用恢復是物理復制業(yè)務側如果在這期間有新寫入會丟失這部分數(shù)據(jù)所以誤操作發(fā)生后第一時間要停止業(yè)務寫入再執(zhí)行恢復。其實最理想的方案是開啟binlog并用binlog2sql這類工具做行級回滾但這類工具的部署和學習成本較高。如果團隊剛起步備份表方案先頂上,后續(xù)再逐步完善。6.3 主鍵沖突與唯一鍵沖突處理批量導入數(shù)據(jù)時最容易碰到的就是主鍵或唯一鍵沖突。常見場景從A庫導入B庫、重新跑批任務、數(shù)據(jù)回刷。我通常用INSERT ... ON DUPLICATE KEY UPDATE來平滑處理INSERT INTO user_profile (user_id, nickname, level, update_time) VALUES (10001, 張三, 5, NOW()) ON DUPLICATE KEY UPDATE nickname VALUES(nickname), level VALUES(level), update_time NOW();這個寫法的含義是有沖突就更新沒沖突就插入。用起來要格外小心它會覆蓋目標記錄的全部字段如果只想更新部分字段就只列出那幾列。還有一個容易被忽視的點這個語句對唯一鍵沖突同樣生效不一定非主鍵不可。如果是純導入場景不想覆蓋原有數(shù)據(jù)那就用INSERT IGNORE遇到?jīng)_突直接跳過。兩種寫法差異很大先想清楚業(yè)務意圖再選我見過因為用錯導致數(shù)據(jù)被覆蓋寫壞的教訓很深刻。7. 腳本管理的工程化實踐腳本寫得再好沒有一套管理規(guī)范時間一長就變成一團亂麻。我自己是從下面幾件事里受益最多的分享出來。版本管理。數(shù)據(jù)庫腳本也是代碼必須進版本庫。有些公司把SQL腳本扔在共享文件夾里版本靠文件名標注v2_final_最終版這種管理方式遲早出事。我的習慣是每個數(shù)據(jù)庫變更腳本按日期和序號命名比如20240115_01_add_index_orders.sql提交到統(tǒng)一的代碼倉庫和代碼一起評審、一起發(fā)布。命名規(guī)范。腳本命名建議包含三個要素操作對象、操作類型、日期。db_backup_20240115.sh比backup.sh好在哪一年后你翻出來不用打開文件就知道這個腳本是干什么的、什么時候寫的、針對哪個庫的。敏感信息處理。腳本里直接寫數(shù)據(jù)庫密碼是大忌。我現(xiàn)在的基本做法是腳本從環(huán)境變量讀取密碼環(huán)境變量由部署平臺注入代碼庫里只保留模板。雖然多了一道工序但密碼泄露的風險大幅降低。執(zhí)行前評審。涉及生產(chǎn)庫的DDL和不常見DML無論多緊急都要先走評審。哪怕是DBA自己執(zhí)行的腳本也先在測試環(huán)境完整跑一遍確認影響行數(shù)在預期范圍內(nèi)再上生產(chǎn)。這個習慣幫我擋掉了至少三次足以釀成大事故的操作。我個人還有一個小習慣每個核心腳本開頭都用注釋寫清楚這腳本什么時候用、怎么用、踩過哪些坑。這個習慣救過我很多次。半年后你面對一個陌生或者陌生的腳本注釋里那三行字比任何文檔都管用。有一次團隊里一位同事半夜調備份恢復正是靠著腳本頭部注釋里的注意該腳本依賴/data/backup/.env文件存在快速定位了問題少走了不少彎路。做數(shù)據(jù)庫運維這些年最大的體會是所謂常用腳本不是一份到處都能抄的標準答案而是你在一次次故障處理、一次次數(shù)據(jù)恢復、一次次深夜值班中沉淀下來的自己的答案。今天的這些腳本是我實踐中的一部分積累希望能給你的腳本庫帶來一些靈感。你在實際工作里積累了什么好用的腳本或者踩過什么獨特的坑歡迎一起聊聊也許你踩過的那個坑正好是我下一個腳本要解決的問題。