MySQL中誤刪數(shù)據(jù)恢復(fù)的3種極限操作分享
一、概述
之前開發(fā)同事紅著眼睛跑來找我："線上數(shù)據(jù)庫的用戶表被我DELETE了，沒加WHERE條件。"
我的第一反應(yīng)是看他有沒有帶行李箱。
開玩笑歸開玩笑，數(shù)據(jù)恢復(fù)這件事我確實(shí)做過很多次。有成功的，也有失敗的。失敗的那次是因?yàn)閎inlog被清理了，我們丟了三天的數(shù)據(jù)，至今想起來都心有余悸。
這篇文章把MySQL數(shù)據(jù)恢復(fù)的幾種方法都寫出來，包括成功的案例和失敗的教訓(xùn)。希望你永遠(yuǎn)用不上，但如果用上了，希望能幫你把數(shù)據(jù)撈回來。
恢復(fù)方法概覽
根據(jù)數(shù)據(jù)丟失的場景和備份情況，主要有以下幾種恢復(fù)方式：
- binlog恢復(fù)：利用MySQL的二進(jìn)制日志回放數(shù)據(jù)
- 備份恢復(fù)：從物理備份或邏輯備份還原
- 第三方工具：使用專業(yè)工具直接從數(shù)據(jù)文件恢復(fù)
每種方法都有前提條件和適用場景，后面會(huì)詳細(xì)說明。
環(huán)境信息
MySQL版本：5.7 / 8.0
存儲(chǔ)引擎：InnoDB
備份方式：mysqldump、xtrabackup
binlog格式：ROW（推薦）
二、binlog恢復(fù)——最常用的救命稻草
binlog恢復(fù)原理
MySQL的binlog記錄了所有對(duì)數(shù)據(jù)的修改操作。如果binlog格式是ROW，不僅記錄SQL語句，還記錄具體修改了哪些行的哪些列。這就為數(shù)據(jù)恢復(fù)提供了可能。
誤刪除操作在binlog中的記錄大概是這樣的：
DELETE FROM users WHERE id=123 # binlog中記錄的是： # 被刪除行的完整數(shù)據(jù)
理論上，只要把這些被刪除的數(shù)據(jù)"反轉(zhuǎn)"成INSERT語句，就能恢復(fù)。
前提條件檢查
-- 確認(rèn)binlog是否開啟 SHOW VARIABLES LIKE 'log_bin'; -- 必須是ON -- 確認(rèn)binlog格式 SHOW VARIABLES LIKE 'binlog_format'; -- 必須是ROW，STATEMENT格式無法精確恢復(fù) -- 確認(rèn)binlog保留策略 SHOW VARIABLES LIKE 'expire_logs_days'; SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; -- MySQL 8.0 -- 查看當(dāng)前的binlog文件 SHOW BINARY LOGS; -- 確認(rèn)誤操作發(fā)生在哪個(gè)binlog文件中 SHOW MASTER STATUS;
恢復(fù)步驟
場景：DELETE語句誤刪了users表的數(shù)據(jù)
第一步：確定誤操作的時(shí)間點(diǎn)和位置
# 查找誤操作的binlog位置 mysqlbinlog --base64-output=decode-rows -vv /var/lib/mysql/binlog.000123 | grep -A 20 "DELETE FROM.*users" # 或者用時(shí)間范圍過濾 mysqlbinlog --start-datetime="2024-01-15 14:00:00" --stop-datetime="2024-01-15 15:00:00" \ --base64-output=decode-rows -vv /var/lib/mysql/binlog.000123 > /tmp/binlog_analysis.txt
第二步：解析binlog獲取被刪除的數(shù)據(jù)
# 完整解析binlog mysqlbinlog --base64-output=decode-rows -vv \ --start-position=4 --stop-position=999999 \ /var/lib/mysql/binlog.000123 > /tmp/binlog_full.txt # 在解析結(jié)果中查找DELETE操作 grep -A 50 "### DELETE FROM \`mydb\`.\`users\`" /tmp/binlog_full.txt
解析結(jié)果示例：
### DELETE FROM `mydb`.`users`
### WHERE
### @1=123
### @2='john_doe'
### @3='john@example.com'
### @4='2024-01-01 10:00:00'
第三步：生成恢復(fù)SQL
這里我用一個(gè)Python腳本來自動(dòng)轉(zhuǎn)換：
#!/usr/bin/env python3
# binlog2sql.py - 將binlog中的DELETE轉(zhuǎn)換為INSERT
import re
import sys
def parse_binlog_delete(content, table_name):
"""解析binlog中的DELETE語句，生成INSERT語句"""
pattern = rf"### DELETE FROM `\w+`\.`{table_name}`\n((?:###.*\n)+)"
matches = re.findall(pattern, content)
insert_statements = []
for match in matches:
# 提取字段值
values = []
for line in match.strip().split('\n'):
if line.startswith('### @'):
# 提取值部分
value = line.split('=', 1)[1]
values.append(value)
if values:
sql = f"INSERT INTO {table_name} VALUES ({', '.join(values)});"
insert_statements.append(sql)
return insert_statements
if __name__ == "__main__":
with open(sys.argv[1], 'r') as f:
content = f.read()
sqls = parse_binlog_delete(content, 'users')
for sql in sqls:
print(sql)
使用方法：
python3 binlog2sql.py /tmp/binlog_full.txt > /tmp/recovery.sql # 檢查生成的SQL head -20 /tmp/recovery.sql # 確認(rèn)無誤后執(zhí)行恢復(fù) mysql -u root -p mydb < /tmp/recovery.sql
使用binlog2sql工具
上面的手工方法適合學(xué)習(xí)原理，生產(chǎn)環(huán)境我推薦使用成熟的開源工具：
# 安裝binlog2sql pip install binlog2sql # 或者從GitHub安裝最新版 git clone https://github.com/danfengcao/binlog2sql.git cd binlog2sql pip install -r requirements.txt # 生成回滾SQL（把DELETE轉(zhuǎn)成INSERT） python binlog2sql.py -h127.0.0.1 -P3306 -uroot -p'password' -d mydb -t users \ --start-datetime="2024-01-15 14:00:00" --stop-datetime="2024-01-15 15:00:00" \ --flashback > /tmp/rollback.sql # 參數(shù)說明： # --flashback: 生成回滾SQL # -B: 只分析指定的binlog文件
binlog恢復(fù)的局限性
- binlog必須開啟且保留：如果binlog被清理或沒開啟，就沒辦法了
- 必須是ROW格式：STATEMENT格式只記錄SQL，不記錄具體數(shù)據(jù)
- 大量數(shù)據(jù)恢復(fù)效率低：需要遍歷binlog，數(shù)據(jù)量大時(shí)很慢
- 不能恢復(fù)DROP TABLE：表被刪除后，后續(xù)的恢復(fù)SQL無法執(zhí)行
三、備份恢復(fù)——最可靠的保險(xiǎn)
mysqldump邏輯備份恢復(fù)
如果有每天的mysqldump備份，恢復(fù)流程相對(duì)簡單：
# 1. 找到最近的備份文件 ls -la /backup/mysql/ # -rw-r--r-- 1 root root 1.2G Jan 15 03:00 mydb_20240115.sql.gz # 2. 恢復(fù)備份（到臨時(shí)數(shù)據(jù)庫） mysql -u root -p -e "CREATE DATABASE mydb_recovery" gunzip -c /backup/mysql/mydb_20240115.sql.gz | mysql -u root -p mydb_recovery # 3. 從臨時(shí)數(shù)據(jù)庫提取需要的數(shù)據(jù) mysqldump -u root -p mydb_recovery users > /tmp/users_backup.sql # 4. 恢復(fù)到生產(chǎn)庫 mysql -u root -p mydb < /tmp/users_backup.sql # 5. 如果還需要備份后到誤操作前的數(shù)據(jù)，用binlog補(bǔ) mysqlbinlog --start-datetime="2024-01-15 03:00:00" \ --stop-datetime="2024-01-15 14:00:00" \ --database=mydb /var/lib/mysql/binlog.* | mysql -u root -p mydb
xtrabackup物理備份恢復(fù)
xtrabackup恢復(fù)更快，但操作也更復(fù)雜：
# 1. 準(zhǔn)備備份（如果是增量備份需要先合并） xtrabackup --prepare --target-dir=/backup/full # 2. 停止MySQL systemctl stop mysqld # 3. 備份當(dāng)前數(shù)據(jù)目錄 mv /var/lib/mysql /var/lib/mysql.bak # 4. 恢復(fù)備份 xtrabackup --copy-back --target-dir=/backup/full # 5. 修復(fù)權(quán)限 chown -R mysql:mysql /var/lib/mysql # 6. 啟動(dòng)MySQL systemctl start mysqld # 7. 用binlog補(bǔ)充備份后的數(shù)據(jù) # 先找到備份時(shí)的binlog位置 cat /backup/full/xtrabackup_binlog_info # binlog.000123 456789 mysqlbinlog --start-position=456789 /var/lib/mysql/binlog.000123 | mysql -u root -p
部分表恢復(fù)（不影響其他表）
有時(shí)候不想全量恢復(fù)，只恢復(fù)特定的表：
# 方法1：從備份文件提取特定表 # 如果是mysqldump的備份 sed -n '/^-- Table structure for table `users`/,/^-- Table structure for table/p' backup.sql > users.sql # 方法2：使用mydumper/myloader（支持單表恢復(fù)） # 安裝 yum install mydumper # 備份時(shí)每個(gè)表一個(gè)文件 mydumper -u root -p password -B mydb -o /backup/mydumper/ # 恢復(fù)單個(gè)表 myloader -u root -p password -B mydb -d /backup/mydumper/ -T users
時(shí)間點(diǎn)恢復(fù)（Point-in-Time Recovery）
這是最完整的恢復(fù)方式，可以恢復(fù)到任意時(shí)間點(diǎn)：
# 1. 恢復(fù)最近的全量備份 mysql -u root -p < /backup/full_backup.sql # 2. 確定備份結(jié)束時(shí)的binlog位置 # 通常備份文件開頭會(huì)有類似信息： # -- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000100', MASTER_LOG_POS=154; # 3. 重放binlog到指定時(shí)間點(diǎn) mysqlbinlog --start-position=154 \ --stop-datetime="2024-01-15 13:59:00" \ /var/lib/mysql/binlog.000100 /var/lib/mysql/binlog.000101 | mysql -u root -p # 注意：stop-datetime要設(shè)置在誤操作之前
四、第三方工具恢復(fù)——最后的希望
當(dāng)binlog和備份都沒有時(shí)，還有一些第三方工具可以嘗試從數(shù)據(jù)文件直接恢復(fù)。
undrop-for-innodb
這個(gè)工具可以從InnoDB數(shù)據(jù)文件中恢復(fù)被DELETE的數(shù)據(jù)：
# 安裝（需要編譯） git clone https://github.com/twindb/undrop-for-innodb.git cd undrop-for-innodb make # 恢復(fù)步驟 # 1. 停止MySQL（非常重要！繼續(xù)運(yùn)行可能覆蓋數(shù)據(jù)） systemctl stop mysqld # 2. 復(fù)制數(shù)據(jù)文件 cp /var/lib/mysql/mydb/users.ibd /tmp/recovery/ # 3. 提取表結(jié)構(gòu) # 需要從frm文件或備份中獲取CREATE TABLE語句 # MySQL 8.0需要從information_schema獲取 # 4. 解析ibd文件 ./c_parser -6f /tmp/recovery/users.ibd -t users.sql > /tmp/recovery/users_data.tsv # 5. 將TSV數(shù)據(jù)導(dǎo)入到新表 # 根據(jù)解析結(jié)果生成INSERT語句
percona-data-recovery-tool
Percona提供的數(shù)據(jù)恢復(fù)工具，功能更強(qiáng)大
詳細(xì)文檔參考：https://github.com/percona/percona-data-recovery-tool-for-innodb
數(shù)據(jù)恢復(fù)公司
如果以上方法都失敗了，而數(shù)據(jù)又非常重要，可以考慮專業(yè)的數(shù)據(jù)恢復(fù)公司。他們有更專業(yè)的工具和經(jīng)驗(yàn)。但要注意：
- 費(fèi)用很高（可能數(shù)萬到數(shù)十萬）
- 不保證100%成功
- 數(shù)據(jù)安全性需要評(píng)估
五、預(yù)防措施——后悔藥
數(shù)據(jù)恢復(fù)永遠(yuǎn)是最后的手段，預(yù)防才是關(guān)鍵。
備份策略
# /etc/cron.d/mysql_backup # 每天凌晨3點(diǎn)全量備份 0 3 * * * root /usr/local/bin/mysql_backup.sh full # 每小時(shí)增量備份 0 * * * * root /usr/local/bin/mysql_backup.sh incremental
備份腳本示例：
#!/bin/bash
# mysql_backup.sh
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=7
case "$1" in
full)
mysqldump -u root -p'password' --all-databases --single-transaction \
--master-data=2 --flush-logs | gzip > ${BACKUP_DIR}/full_${DATE}.sql.gz
# 或使用xtrabackup
# xtrabackup --backup --target-dir=${BACKUP_DIR}/full_${DATE}
;;
incremental)
# xtrabackup增量備份
LAST_FULL=$(ls -1d ${BACKUP_DIR}/full_* | tail -1)
xtrabackup --backup --target-dir=${BACKUP_DIR}/inc_${DATE} \
--incremental-basedir=${LAST_FULL}
;;
esac
# 清理過期備份
find ${BACKUP_DIR} -name "*.sql.gz" -mtime +${RETENTION_DAYS} -delete
find ${BACKUP_DIR} -type d -name "full_*" -mtime +${RETENTION_DAYS} -exec rm -rf {} \;
binlog配置
# /etc/my.cnf [mysqld] # 開啟binlog log-bin = /var/lib/mysql/binlog server-id = 1 # 使用ROW格式（重要?。? binlog_format = ROW # 記錄完整的行數(shù)據(jù)（恢復(fù)時(shí)需要） binlog_row_image = FULL # binlog保留天數(shù) expire_logs_days = 7 # MySQL 8.0 # binlog_expire_logs_seconds = 604800 # binlog文件大小 max_binlog_size = 500M # 每次事務(wù)都刷盤（安全但略慢） sync_binlog = 1
權(quán)限控制
-- 生產(chǎn)環(huán)境不要用root -- 創(chuàng)建只有必要權(quán)限的用戶 -- 應(yīng)用程序賬號(hào)（不給DELETE權(quán)限，或者只給特定表） CREATE USER 'app'@'%' IDENTIFIED BY 'password'; GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'app'@'%'; -- 只有特定表允許DELETE GRANT DELETE ON mydb.temp_table TO 'app'@'%'; -- DBA賬號(hào)（有DELETE但需要審計(jì)） CREATE USER 'dba'@'%' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON *.* TO 'dba'@'%';
SQL審計(jì)
# 安裝MySQL Enterprise Audit或第三方審計(jì)插件 # 或者使用general_log（臨時(shí)使用，性能影響大） SET GLOBAL general_log = ON; SET GLOBAL general_log_file = '/var/log/mysql/general.log'; # 使用init_connect記錄連接信息 SET GLOBAL init_connect = 'INSERT INTO mysql.accesslog VALUES(connection_id(), current_user(), now())';
延遲從庫
設(shè)置一個(gè)延遲復(fù)制的從庫，給誤操作提供緩沖時(shí)間：
-- 在從庫上執(zhí)行 CHANGE MASTER TO MASTER_DELAY = 3600; -- 延遲1小時(shí) -- 當(dāng)主庫發(fā)生誤操作時(shí)，從庫還有1小時(shí)的數(shù)據(jù)未同步 -- 可以從延遲從庫恢復(fù)數(shù)據(jù)
DELETE操作規(guī)范
-- 錯(cuò)誤示范（千萬不要?。? DELETE FROM users; -- 正確做法1：先SELECT確認(rèn) SELECT * FROM users WHERE id = 123; -- 確認(rèn)無誤后 DELETE FROM users WHERE id = 123; -- 正確做法2：使用LIMIT DELETE FROM users WHERE status = 'inactive' LIMIT 1000; -- 分批刪除，避免一次性影響太多數(shù)據(jù) -- 正確做法3：開啟事務(wù) BEGIN; DELETE FROM users WHERE id = 123; -- 檢查影響行數(shù) SELECT ROW_COUNT(); -- 確認(rèn)無誤后 COMMIT; -- 如果不對(duì) -- ROLLBACK; -- 正確做法4：先改名再刪除 RENAME TABLE users TO users_to_delete; -- 觀察一段時(shí)間，確認(rèn)無問題后 DROP TABLE users_to_delete;
六、真實(shí)案例復(fù)盤
案例一：成功恢復(fù)——UPDATE沒加WHERE
背景：開發(fā)同事執(zhí)行 UPDATE orders SET status='cancelled'，沒加WHERE條件，影響了500萬訂單。
恢復(fù)過程：
# 1. 第一時(shí)間停止應(yīng)用寫入 # 通知SRE團(tuán)隊(duì)暫停相關(guān)服務(wù) # 2. 確認(rèn)binlog可用 mysql -e "SHOW BINARY LOGS" | tail -5 # 3. 找到誤操作位置 mysqlbinlog --base64-output=decode-rows -vv /var/lib/mysql/binlog.000156 \ | grep -B5 "UPDATE.*orders.*SET.*status.*cancelled" | head -20 # 4. 使用binlog2sql生成回滾SQL python binlog2sql.py -h127.0.0.1 -uroot -p -d orderdb -t orders \ --start-position=12345 --stop-position=67890 \ --flashback > /tmp/rollback.sql # 5. 驗(yàn)證回滾SQL head -100 /tmp/rollback.sql wc -l /tmp/rollback.sql # 確認(rèn)行數(shù)與影響行數(shù)一致 # 6. 執(zhí)行恢復(fù) mysql -u root -p orderdb < /tmp/rollback.sql # 7. 驗(yàn)證數(shù)據(jù) mysql -e "SELECT status, COUNT(*) FROM orderdb.orders GROUP BY status"
耗時(shí)：從發(fā)現(xiàn)問題到恢復(fù)完成，約2小時(shí)。
案例二：部分成功——binlog不全
背景：凌晨運(yùn)維人員誤執(zhí)行 DROP DATABASE analytics，發(fā)現(xiàn)時(shí)已過去6小時(shí)。
問題：
- binlog保留了7天，但DROP操作會(huì)導(dǎo)致后續(xù)該庫的binlog無法回放
- 最近的備份是前一天凌晨
恢復(fù)過程：
# 1. 恢復(fù)昨天的備份 mysql -u root -p < /backup/analytics_20240114.sql # 2. 嘗試回放binlog到DROP之前 # 找到DROP操作的位置 mysqlbinlog /var/lib/mysql/binlog.000155 | grep -n "DROP DATABASE" # 行號(hào): 156789 # 3. 回放binlog mysqlbinlog --stop-position=156788 /var/lib/mysql/binlog.000155 | mysql -u root -p analytics
結(jié)果：恢復(fù)了到DROP操作前1秒的數(shù)據(jù)，丟失了約18小時(shí)的數(shù)據(jù)（從DROP發(fā)生到備份之間）。
教訓(xùn)：增加binlog備份頻率，使用延遲從庫。
案例三：失敗——binlog已被清理
背景：數(shù)據(jù)庫磁盤空間緊張，運(yùn)維人員執(zhí)行了 PURGE BINARY LOGS BEFORE '2024-01-10'。3天后發(fā)現(xiàn)一周前的數(shù)據(jù)有問題需要恢復(fù)。
問題：
- 需要恢復(fù)的數(shù)據(jù)在已清理的binlog中
- 最近的備份也是清理后的
嘗試：
- undrop-for-innodb工具無法恢復(fù)（數(shù)據(jù)已被覆蓋太多）
- 聯(lián)系數(shù)據(jù)恢復(fù)公司，報(bào)價(jià)15萬，且不保證成功
結(jié)果：數(shù)據(jù)徹底丟失。
教訓(xùn)：
binlog清理必須確認(rèn)有對(duì)應(yīng)時(shí)間點(diǎn)的備份
建立binlog單獨(dú)的存儲(chǔ)和備份機(jī)制
重要操作需要審批流程
七、總結(jié)
恢復(fù)方法對(duì)比
| 方法 | 前提條件 | 恢復(fù)速度 | 數(shù)據(jù)完整性 | 難度 |
|---|---|---|---|---|
| binlog恢復(fù) | binlog開啟且保留 | 中等 | 高 | 中等 |
| mysqldump恢復(fù) | 有備份文件 | 慢 | 取決于備份時(shí)間 | 簡單 |
| xtrabackup恢復(fù) | 有物理備份 | 快 | 取決于備份時(shí)間 | 中等 |
| 第三方工具 | 數(shù)據(jù)未被覆蓋 | 很慢 | 不確定 | 困難 |
核心要點(diǎn)
- 備份是底線：沒有備份，神仙也救不了
- binlog用ROW格式：STATEMENT格式無法精確恢復(fù)
- 權(quán)限要最小化：能不給DELETE就不給
- 大表操作要分批：避免一次性影響太多數(shù)據(jù)
- 延遲從庫是保險(xiǎn)：給誤操作留出反應(yīng)時(shí)間
- 事后復(fù)盤很重要：每次事故都是改進(jìn)的機(jī)會(huì)
緊急情況處理流程
發(fā)現(xiàn)誤操作
│
▼
立即停止寫入（能停就停）
│
▼
評(píng)估影響范圍
│
├── 影響小 ──→ 直接binlog恢復(fù)
│
└── 影響大 ──→ 通知相關(guān)人員
│
▼
制定恢復(fù)方案
│
▼
準(zhǔn)備回滾環(huán)境
│
▼
執(zhí)行恢復(fù)并驗(yàn)證
│
▼
恢復(fù)業(yè)務(wù)訪問
│
▼
事后復(fù)盤總結(jié)
到此這篇關(guān)于MySQL中誤刪數(shù)據(jù)恢復(fù)的3種極限操作分享的文章就介紹到這了,更多相關(guān)MySQL誤刪數(shù)據(jù)恢復(fù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
MySQL時(shí)間設(shè)置注意事項(xiàng)的深入總結(jié)
這篇文章主要給大家介紹了關(guān)于MySQL時(shí)間設(shè)置注意事項(xiàng)的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-05-05
Mysql創(chuàng)建視圖中文亂碼如何修改docker里的配置
這篇文章主要介紹了Mysql創(chuàng)建視圖中文亂碼如何修改docker里的配置,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2023-10-10
關(guān)于Mysql如何設(shè)計(jì)高性能的數(shù)據(jù)庫
這篇文章主要介紹了關(guān)于Mysql如何設(shè)計(jì)高性能的數(shù)據(jù)庫,mysql支持的數(shù)據(jù)類型非常多，選擇正確的數(shù)據(jù)類型對(duì)于獲得高性能至關(guān)重要,本文就來詳細(xì)說明如何設(shè)計(jì)出高性能的數(shù)據(jù)庫,需要的朋友可以參考下2023-07-07
這篇文章主要介紹了MySQL?配置主從復(fù)制實(shí)踐分享，通過檢測通信展開詳情，具有一定的參考價(jià)值，需要的小伙伴可以參考一下2022-07-07
這篇文章主要介紹了MySQL與SQL Server的一些區(qū)別淺析,本文羅列了MySQL與SQL Server的25個(gè)不同的地方,并對(duì)它們的分頁技術(shù)的不同做了講解,需要的朋友可以參考下2014-08-08
MySQL通過日志恢復(fù)數(shù)據(jù)的操作步驟
在MySQL中恢復(fù)誤刪除的數(shù)據(jù)是一個(gè)常見但復(fù)雜的問題,具體的方法取決于幾個(gè)因素,包括您是否有備份、使用的是哪種存儲(chǔ)引擎（如InnoDB或MyISAM）、以及您的數(shù)據(jù)庫配置等,本文給大家介紹了MySQL通過日志恢復(fù)數(shù)據(jù)的操作步驟,需要的朋友可以參考下2024-12-12
MySQL文件權(quán)限是用來控制用戶對(duì)數(shù)據(jù)庫文件以及目錄的操作權(quán)限,在MySQL中,這些權(quán)限通常由系統(tǒng)管理員分配,通過GRANT和REVOKE語句進(jìn)行管理,本文給大家介紹了MySQL文件權(quán)限存在的安全問題和解決方案,需要的朋友可以參考下2024-07-07
這篇文章主要介紹了mysql 安全管理，MySQL服務(wù)器的安全基礎(chǔ)是用戶應(yīng)該對(duì)他們需要的數(shù)據(jù)具有適當(dāng)?shù)脑L問權(quán)，既不能多也不能少，換句話說，用戶不能對(duì)過多的數(shù)據(jù)具有過多的訪問權(quán)，下面?zhèn)z看看文章詳細(xì)內(nèi)容吧2021-10-10
MySQL配置文件my.cnf優(yōu)化詳解(mysql5.5)
這篇文章主要介紹了MySQL配置文件my.cnf優(yōu)化詳解,需要的朋友可以參考下2014-12-12
這篇文章主要介紹了MySql存儲(chǔ)過程參數(shù)的入門使用，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04