本番のDBがあったとして、それに近いデータでテストすることは大変重要！
本番なら気づけたのにな〜！というのが格段に減る。
でも本番のデータをコピーして使うのは怖い場合があって(例えば個人情報)、万が一お漏らししても問題のないようにマスキングして使いたい。
そんなことを考える、個人的なメモ。

DBの構成

本番とテスト(staging)があるとするじゃろ。

hoge_prod が本番用DBのホスト、 hoge_stgがテスト用DBのホストじゃ。

テーブル

create table employees (
id BIGINT NOT NULL AUTO_INCREMENT,
name varchar(100),
email varchar(100),
secret_num INT,
PRIMARY KEY (id));

テストデータ

insert into employees (name, email, secret_num) values ("kaiba", "[email protected]", 1234);
insert into employees (name, email, secret_num) values ("waketi", "[email protected]", 222);
insert into employees (name, email, secret_num) values ("ematette", "[email protected]", 123);

+----+----------+--------------------------+------------+
| id | name | email | secret_num |
+----+----------+--------------------------+------------+
| 1 | kaiba | [email protected] | 1234 |
| 2 | waketi | [email protected] | 2222 |
| 3 | ematette | [email protected] | 123 |
+----+----------+--------------------------+------------+

本番のデータをコピーする

巨大なDBであれば、スナップショットをコピーしてやるのが良いですが、mysqlのuserテーブルも本番のものになるので、テスト用のユーザにして変更し直す必要があります。
小さいDBであればmysqldumpでテスト対象のDBだけ上書きしてやるのが楽。
本番をdumpして、テストに流す。逆にすると死にます。

mysqldump -uprod_user -p******* -hhoge_prod my_database | mysql -utest -pTEST -hhoge_stg my_database

まずいデータをマスクする

update employees set name=concat("name",id), 
email=concat("dev+",id,"@example.com"), 
secret_num=1111;

+----+-------------------+-------------------+------------+
| id | name | email | secret_num |
+----+-------------------+-------------------+------------+
| 1 | name1 | [email protected] | 1111 |
| 2 | name2 | [email protected] | 1111 |
| 3 | name3 | [email protected] | 1111 |
+----+-------------------+-------------------+------------+

やったぜ。
concatでidと結合してやるのがミソ。

という個人的なメモでした。