mysqlデータベースデータの削除とリカバリ
143253 ワード
Part 1削除データ、truncateとdeleteの違い
変換元:http://blog.is36.com/mysql_difference_of_truncate_and_delete/
truncateは全体削除(速度が速い)であり、deleteは1つずつ削除(速度が遅い)である.
truncateはサーバlogを書かず、deleteはサーバlogを書き、つまりtruncateの効率がdeleteより高い原因である.(delete whereを持たない文はログを書かない)truncateはtrigger(トリガ)をアクティブにしませんが、Identity(識別列、自増フィールド)はリセットされ、自増列が初期値に設定され、元のID数ではなく1から記録されます.delete削除後も、Identityは削除された最近のレコードIDに1を加えて記録されます.
テーブル内のレコードの一部を削除するだけで、where条件に合わせるにはDELETE文しか使用できません.DELETE FROM wp_comments WHERE……
Part 2 msqlでwhere文のないdeleteとupdateを制限する
変換元:http://blog.csdn.net/shgh_2004/article/details/53150276
本番環境でUPDATE,DELETE文を使用してデータを操作している場合、追加すべきWHERE条件を忘れてしまうと、結果が予想できない場合があります.通常のビジネスでは、すべてのレコードを更新または削除することはありません.
1.update設定をブロックする(sql_safe_updates)
sql_safe_updatesというMySQLが持っているパラメータは私たちの問題を完璧に解決することができ、このパラメータはオンラインで変更することができますよ~このパラメータがオンの場合、UPDATE文の後にWHERE条件を携帯しなければなりません.そうしないとERRORが報告されます.
パラメータsql_safe_UPDATE文がWHERE条件を持たないとエラーが発生します.
2.delete設定をブロックする
mysql削除を直接制限MySQLを起動するときにパラメータ-U-U、--safe-updates Only allow UPDATE and DELETE that uses keysを追加します.彼の役割はdeleteを実行するときに条件文が付いていないことを防止し、whereを付けなければ文は実行しないことです.
Part 3 MySQL誤操作後データ復旧(update,delete where条件忘れ)
変換元:http://www.cnblogs.com/gomysql/p/3582058.html
データベースの日常的なメンテナンスでは、開発者が最も頭を悩ませ、SQL文に問題が書かれているため、サーバに問題が発生し、リソースが消費されることが多い.最も危険な操作はDMLの操作をする時whereの条件をつけることを忘れて、全表の更新を招いて、これは運行維持あるいはDBAの私達としてどのように処理しますか?次に、updateとdelete操作に対してwhere条件を忘れて全テーブルを更新する処理方法を説明します.
一.update where条件誤操作リカバリデータの忘れ(binglogフォーマットはROWである必要があります)
1.テスト用データシートの作成
2.試験データの挿入
3.idが2に等しいユーザのアドレスをzhuhaiに変更する必要があり、update時にwhere条件が追加されていない
4.リカバリを開始し、オンラインでは複雑であるべきで、データが再び汚染されないように、まず時計をロックしなければならない.(テーブルをロックして、どのバイナリ・ログが書かれているかを確認します)
5.バイナリ・ログを分析し、関連レコードを見つけ、更新時にaddress='zhuhai'であり、ログでフィルタできます.
各行の変化が記録されているのが見えますが、binglogフォーマットがrowでなければならない理由でもあります.このうち@1,@2,@3,@4は,それぞれテーブル中のid,name,sex,addressフィールドに対応する.ここを見て少し分かったと思います.はい、そうです.推測しました.関連レコードをsql文に変換し、データベースを再インポートします.
6.分析処理を処理するバイナリログ
ここはsedが少し複雑で、子供靴たちがよく自分で研究する必要があります.ここではあまり言いません.
ファイルの@1,@2,@3,@4をt 1テーブルのid,name,sex,addressフィールドに置き換え、最後のフィールドの「,」番号を削除します.
7.ここまでログが処理されたので、今インポートすればいい(データをインポートした後、テーブルをロック解除する);
データが完全に復元されていることがわかります.この方法の利点は、迅速で便利です.
二.delete忘れwhere条件誤削除リカバリ(binglogフォーマットはROWである必要があります)
実はupdateと条件の差は多くありませんが、この処理はもっと簡単です.ここでは上の表でテストしましょう.
1.アナログ誤削除データ
2.binglogで関連レコードを検索する
3.レコードをSQL文に変換
4.データのインポート、データ整合性の検証
ここまで来るとデータが完全に戻ってきます.binglogフォーマットをrowに設定するのはメリットとデメリットがあり、各行の実際の変化を記録し、プライマリ・セカンダリ・レプリケーションでも問題が発生しにくいというメリットがあります.ただし、ローごとの変更を記録すると、ディスクが大量に消費され、プライマリ・セカンダリ・レプリケーションで帯域幅が消費されます.rowを使うかmixedを使うかは、実際の仕事で自分で測る必要がありますが、全体的にbinglogのフォーマットがrowに設定されているのは、不二の選択です.
まとめ:
だから、データベースの操作の過程で私たちは特に注意する必要があります.もちろん、開発側は権限の制御が必要ですが、パラメータが私たちの問題を解決することができます.このような問題が発生する心配はありません.
[mysql]段落でこのパラメータをオンにします.
これにより、DML操作中にwhere条件を追加することを忘れた場合、mysqldサーバは操作を実行しません.
変換元:http://blog.is36.com/mysql_difference_of_truncate_and_delete/
truncateは全体削除(速度が速い)であり、deleteは1つずつ削除(速度が遅い)である.
truncateはサーバlogを書かず、deleteはサーバlogを書き、つまりtruncateの効率がdeleteより高い原因である.(delete whereを持たない文はログを書かない)truncateはtrigger(トリガ)をアクティブにしませんが、Identity(識別列、自増フィールド)はリセットされ、自増列が初期値に設定され、元のID数ではなく1から記録されます.delete削除後も、Identityは削除された最近のレコードIDに1を加えて記録されます.
テーブル内のレコードの一部を削除するだけで、where条件に合わせるにはDELETE文しか使用できません.DELETE FROM wp_comments WHERE……
Part 2 msqlでwhere文のないdeleteとupdateを制限する
変換元:http://blog.csdn.net/shgh_2004/article/details/53150276
本番環境でUPDATE,DELETE文を使用してデータを操作している場合、追加すべきWHERE条件を忘れてしまうと、結果が予想できない場合があります.通常のビジネスでは、すべてのレコードを更新または削除することはありません.
1.update設定をブロックする(sql_safe_updates)
sql_safe_updatesというMySQLが持っているパラメータは私たちの問題を完璧に解決することができ、このパラメータはオンラインで変更することができますよ~このパラメータがオンの場合、UPDATE文の後にWHERE条件を携帯しなければなりません.そうしないとERRORが報告されます.
# sql_safe_updates=0,
[email protected] : test 07:58:34> set sql_safe_updates=0;
Query OK, 0 rows affected (0.00 sec)
[email protected] : test 07:58:43> show variables like 'sql_safe_updates'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | sql_safe_updates | OFF | +------------------+-------+ 1 row in set (0.00 sec) # sql_safe_updates=1, root@127.0.0.1 : test 08:00:00> set sql_safe_updates=1; Query OK, 0 rows affected (0.00 sec) [email protected] : test 08:00:11> show variables like 'sql_safe_updates'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | sql_safe_updates | ON | +------------------+-------+ 1 row in set (0.00 sec) [email protected] : test 08:00:27> update t set aaa='aaa'; ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY columnパラメータsql_safe_UPDATE文がWHERE条件を持たないとエラーが発生します.
2.delete設定をブロックする
mysql削除を直接制限MySQLを起動するときにパラメータ-U-U、--safe-updates Only allow UPDATE and DELETE that uses keysを追加します.彼の役割はdeleteを実行するときに条件文が付いていないことを防止し、whereを付けなければ文は実行しないことです.
Part 3 MySQL誤操作後データ復旧(update,delete where条件忘れ)
変換元:http://www.cnblogs.com/gomysql/p/3582058.html
データベースの日常的なメンテナンスでは、開発者が最も頭を悩ませ、SQL文に問題が書かれているため、サーバに問題が発生し、リソースが消費されることが多い.最も危険な操作はDMLの操作をする時whereの条件をつけることを忘れて、全表の更新を招いて、これは運行維持あるいはDBAの私達としてどのように処理しますか?次に、updateとdelete操作に対してwhere条件を忘れて全テーブルを更新する処理方法を説明します.
一.update where条件誤操作リカバリデータの忘れ(binglogフォーマットはROWである必要があります)
1.テスト用データシートの作成
mysql> create table t1 (
-> id int unsigned not null auto_increment,
-> name char(20) not null,
-> sex enum('f','m') not null default 'm',
-> address varchar(30) not null,
-> primary key(id)
-> );
Query OK, 0 rows affected (0.31 sec)
mysql> 2.試験データの挿入
mysql> insert into t1 (name,sex,address)values('daiiy','m','guangzhou');
Query OK, 1 row affected (0.01 sec)
mysql> insert into t1 (name,sex,address)values('tom','f','shanghai');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 (name,sex,address)values('liany','m','beijing');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 (name,sex,address)values('lilu','m','zhuhai');
Query OK, 1 row affected (0.05 sec)
mysql> 3.idが2に等しいユーザのアドレスをzhuhaiに変更する必要があり、update時にwhere条件が追加されていない
mysql> select * from t1;
+----+-------+-----+-----------+
| id | name | sex | address |
+----+-------+-----+-----------+
| 1 | daiiy | m | guangzhou |
| 2 | tom | f | shanghai |
| 3 | liany | m | beijing |
| 4 | lilu | m | zhuhai |
+----+-------+-----+-----------+
4 rows in set (0.01 sec)
mysql> update t1 set address='zhuhai';
Query OK, 3 rows affected (0.09 sec)
Rows matched: 4 Changed: 3 Warnings: 0
mysql> select * from t1;
+----+-------+-----+---------+
| id | name | sex | address |
+----+-------+-----+---------+
| 1 | daiiy | m | zhuhai |
| 2 | tom | f | zhuhai |
| 3 | liany | m | zhuhai |
| 4 | lilu | m | zhuhai |
+----+-------+-----+---------+
4 rows in set (0.00 sec)
mysql> 4.リカバリを開始し、オンラインでは複雑であるべきで、データが再び汚染されないように、まず時計をロックしなければならない.(テーブルをロックして、どのバイナリ・ログが書かれているかを確認します)
mysql> lock tables t1 read ;
Query OK, 0 rows affected (0.00 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000024 | 1852 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
mysql> 5.バイナリ・ログを分析し、関連レコードを見つけ、更新時にaddress='zhuhai'であり、ログでフィルタできます.
[root@localhost mysql]# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000024 | grep -B 15 'zhuhai'# at 1629
# at 1679
#140305 10:52:24 server id 1 end_log_pos 1679 Table_map: `db01`.`t1` mapped to number 38
#140305 10:52:24 server id 1 end_log_pos 1825 Update_rows: table id 38 flags: STMT_END_F
### UPDATE db01.t1
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='daiiy' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='guangzhou' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='daiiy' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### UPDATE db01.t1
### WHERE
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='tom' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='shanghai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='tom' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### UPDATE db01.t1
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='liany' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='beijing' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='liany' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */各行の変化が記録されているのが見えますが、binglogフォーマットがrowでなければならない理由でもあります.このうち@1,@2,@3,@4は,それぞれテーブル中のid,name,sex,addressフィールドに対応する.ここを見て少し分かったと思います.はい、そうです.推測しました.関連レコードをsql文に変換し、データベースを再インポートします.
6.分析処理を処理するバイナリログ
[root@localhost mysql]# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000024 | sed -n '/# at 1679/,/COMMIT/p' > t1.txt
[root@localhost mysql]# cat t1.txt
# at 1679
#140305 10:52:24 server id 1 end_log_pos 1679 Table_map: `db01`.`t1` mapped to number 38
#140305 10:52:24 server id 1 end_log_pos 1825 Update_rows: table id 38 flags: STMT_END_F
### UPDATE db01.t1
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='daiiy' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='guangzhou' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='daiiy' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### UPDATE db01.t1
### WHERE
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='tom' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='shanghai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='tom' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### UPDATE db01.t1
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='liany' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='beijing' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### SET
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='liany' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
# at 1825
#140305 10:52:24 server id 1 end_log_pos 1852 Xid = 26
COMMIT/*!*/;
[root@localhost mysql]# ここはsedが少し複雑で、子供靴たちがよく自分で研究する必要があります.ここではあまり言いません.
[root@localhost mysql]# sed '/WHERE/{:a;N;/SET/!ba;s/\([^
]*\)
\(.*\)
\(.*\)/\3
\2
\1/}' t1.txt | sed -r '/WHERE/{:a;N;/@4/!ba;s/### @2.*//g}' | sed 's/### //g;s/\/\*.*/,/g' | sed '/WHERE/{:a;N;/@1/!ba;s/,/;/g};s/#.*//g;s/COMMIT,//g' | sed '/^$/d' > recover.sql [root@localhost mysql]# cat recover.sql
UPDATE db01.t1
SET
@1=1 ,
@2='daiiy' ,
@3=2 ,
@4='guangzhou' ,
WHERE
@1=1 ;
UPDATE db01.t1
SET
@1=2 ,
@2='tom' ,
@3=1 ,
@4='shanghai' ,
WHERE
@1=2 ;
UPDATE db01.t1
SET
@1=3 ,
@2='liany' ,
@3=2 ,
@4='beijing' ,
WHERE
@1=3 ;
[root@localhost mysql]# ファイルの@1,@2,@3,@4をt 1テーブルのid,name,sex,addressフィールドに置き換え、最後のフィールドの「,」番号を削除します.
[root@localhost mysql]# sed -i 's/@1/id/g;s/@2/name/g;s/@3/sex/g;s/@4/address/g' recover.sql
[root@localhost mysql]# sed -i -r 's/(address=.*),/\1/g' recover.sql
[root@localhost mysql]# cat recover.sql
UPDATE db01.t1
SET
id=1 ,
name='daiiy' ,
sex=2 ,
address='guangzhou'
WHERE
id=1 ;
UPDATE db01.t1
SET
id=2 ,
name='tom' ,
sex=1 ,
address='shanghai'
WHERE
id=2 ;
UPDATE db01.t1
SET
id=3 ,
name='liany' ,
sex=2 ,
address='beijing'
WHERE
id=3 ;
[root@localhost mysql]# 7.ここまでログが処理されたので、今インポートすればいい(データをインポートした後、テーブルをロック解除する);
mysql> source recover.sql;
Query OK, 1 row affected (0.12 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from t1;
+----+-------+-----+-----------+
| id | name | sex | address |
+----+-------+-----+-----------+
| 1 | daiiy | m | guangzhou |
| 2 | tom | f | shanghai |
| 3 | liany | m | beijing |
| 4 | lilu | m | zhuhai |
+----+-------+-----+-----------+
4 rows in set (0.00 sec)
mysql> データが完全に復元されていることがわかります.この方法の利点は、迅速で便利です.
二.delete忘れwhere条件誤削除リカバリ(binglogフォーマットはROWである必要があります)
実はupdateと条件の差は多くありませんが、この処理はもっと簡単です.ここでは上の表でテストしましょう.
1.アナログ誤削除データ
mysql> select * from t1;
+----+-------+-----+-----------+
| id | name | sex | address |
+----+-------+-----+-----------+
| 1 | daiiy | m | guangzhou |
| 2 | tom | f | shanghai |
| 3 | liany | m | beijing |
| 4 | lilu | m | zhuhai |
+----+-------+-----+-----------+
4 rows in set (0.00 sec)
mysql> delete from t1;
Query OK, 4 rows affected (0.03 sec)
mysql> select * from t1;
Empty set (0.00 sec)
mysql> 2.binglogで関連レコードを検索する
[root@localhost mysql]# mysqlbinlog --no-defaults --base64-output=decode-rows -v -v mysql-bin.000024 | sed -n '/### DELETE FROM db01.t1/,/COMMIT/p' > delete.txt
[root@localhost mysql]# cat delete.txt
### DELETE FROM db01.t1
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='daiiy' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='guangzhou' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### DELETE FROM db01.t1
### WHERE
### @1=2 /* INT meta=0 nullable=0 is_null=0 */
### @2='tom' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='shanghai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### DELETE FROM db01.t1
### WHERE
### @1=3 /* INT meta=0 nullable=0 is_null=0 */
### @2='liany' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='beijing' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
### DELETE FROM db01.t1
### WHERE
### @1=4 /* INT meta=0 nullable=0 is_null=0 */
### @2='lilu' /* STRING(60) meta=65084 nullable=0 is_null=0 */
### @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### @4='zhuhai' /* VARSTRING(90) meta=90 nullable=0 is_null=0 */
# at 2719
#140305 11:41:00 server id 1 end_log_pos 2746 Xid = 78
COMMIT/*!*/;
[root@localhost mysql]# 3.レコードをSQL文に変換
[root@localhost mysql]# cat delete.txt | sed -n '/###/p' | sed 's/### //g;s/\/\*.*/,/g;s/DELETE FROM/INSERT INTO/g;s/WHERE/SELECT/g;' | sed -r 's/(@4.*),/\1;/g' | sed 's/@[1-9]=//g' > t1.sql
[root@localhost mysql]# cat t1.sql
INSERT INTO db01.t1
SELECT
1 ,
'daiiy' ,
2 ,
'guangzhou' ;
INSERT INTO db01.t1
SELECT
2 ,
'tom' ,
1 ,
'shanghai' ;
INSERT INTO db01.t1
SELECT
3 ,
'liany' ,
2 ,
'beijing' ;
INSERT INTO db01.t1
SELECT
4 ,
'lilu' ,
2 ,
'zhuhai' ;
[root@localhost mysql]# 4.データのインポート、データ整合性の検証
mysql> source t1.sql;
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
Query OK, 1 row affected (0.02 sec)
Records: 1 Duplicates: 0 Warnings: 0
Query OK, 1 row affected (0.02 sec)
Records: 1 Duplicates: 0 Warnings: 0
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select * from t1;
ERROR 1046 (3D000): No database selected
mysql> select * from db01.t1;
+----+-------+-----+-----------+
| id | name | sex | address |
+----+-------+-----+-----------+
| 1 | daiiy | m | guangzhou |
| 2 | tom | f | shanghai |
| 3 | liany | m | beijing |
| 4 | lilu | m | zhuhai |
+----+-------+-----+-----------+
4 rows in set (0.00 sec)
mysql> ここまで来るとデータが完全に戻ってきます.binglogフォーマットをrowに設定するのはメリットとデメリットがあり、各行の実際の変化を記録し、プライマリ・セカンダリ・レプリケーションでも問題が発生しにくいというメリットがあります.ただし、ローごとの変更を記録すると、ディスクが大量に消費され、プライマリ・セカンダリ・レプリケーションで帯域幅が消費されます.rowを使うかmixedを使うかは、実際の仕事で自分で測る必要がありますが、全体的にbinglogのフォーマットがrowに設定されているのは、不二の選択です.
まとめ:
だから、データベースの操作の過程で私たちは特に注意する必要があります.もちろん、開発側は権限の制御が必要ですが、パラメータが私たちの問題を解決することができます.このような問題が発生する心配はありません.
[mysql]段落でこのパラメータをオンにします.
safe-updatesこれにより、DML操作中にwhere条件を追加することを忘れた場合、mysqldサーバは操作を実行しません.
mysql> select * from t1;
+----+------------------+
| id | name |
+----+------------------+
| 1 | yayun |
| 2 | atlas |
| 3 | mysql |
| 6 | good yayun heheh |
+----+------------------+
4 rows in set (0.00 sec)
mysql> delete from t1;
ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
mysql>