 |
|
|
2018 10,16 22：17 |
|
|
久しぶりに
テーブルの変更を行うにあたり、グループIDごとに採番する必要が出てきたので その方法を調べていました。 既にIDというAUTO INCREMENTでPKのカラムがあるけど、それとは別で採番 参考にさせて頂いたブログ http://www.umikabuto.com/blog/archives/5909 UPDATE target as t1
INNER JOIN
(
SELECT tA.group_id, COUNT(tA.group_id) AS seq, tA.id AS dmyid
FROM target as tA, target as tB
WHERE tA.group_id = tB.group_id AND tA.id >= tB.id
GROUP BY tA.group_id, tA.id
) as t2
ON t1.id = t2.dmyid
SET t1.seq = t2.seq; へぇ～、updateでもjoinできるんだ、初めて知った ってか、使う用途がなかったからなぁ ためになったなぁ
PR |
|
|
|
|
2017 11,23 11：20 |
|
|
SELECT
(
CASE dayofweek(now())
WHEN 1 THEN '日曜日'
WHEN 2 THEN '月曜日'
WHEN 3 THEN '火曜日'
WHEN 4 THEN '水曜日'
WHEN 5 THEN '木曜日'
WHEN 6 THEN '金曜日'
WHEN 7 THEN '土曜日'
END
)
AS week
|
|
|
|
|
2017 08,23 18：32 |
|
|
特定のカラムに入っているデータを書き換えたい
用途としては、カラムに画像のURLが入っており、そのURLが変更になったとか
START TRANSACTION;
UPDATE hoge_tbl SET img_url=REPLACE(img_url, "http://hogehoge.net/img/", "https://hogehoge.com/pic/") ;
COMMIT;
みたいなね
この例だと
http://hogehoge.net/img/をhttps://hogehoge.com/pic/に置換します。
|
|
|
|
|
2017 01,18 13：49 |
|
|
安定稼働していたサービスは、とくに変更などの要件などが
なかったから放置していたのですが、 久しぶりに大量のデータを変更欲しいと依頼 その対象のDBにログインをしたら、HDDが72%まで使用していた 依頼のデータ変更をしたのちに、HDDを圧迫している原因を調査したら、 MySQLのバイナリーログが２００を超える数に そんなわけで、今回は、バイナリーログの肥大化の対応 とりあえず、HDDを空けるために、 mysql> show slave status \G で確認（スレーブを使用しているので） mysql> show master logs; で、MySQLが管理しているバイナリーログを一覧で表示 mysql> purge master logs to '削除するログファイル名'; で、ログデータを削除 例えば、mysql-bin.010 とファイル名をした場合、 mysql-bin.009まで削除されます。 mysql> show master logs; で削除されたかどうかを確認。OK！ で、肥大化させないために、バイナリーログの保存期間を設定 MySQLを再起動させたくないので、my.cnfには記載せずに、 mysql> show global variables like 'expire_logs_days'; で、現状の設定を確認したら、０(削除しない)になっていたので mysql> SET GLOBAL expire_logs_days = 30; で、30日に変更 これで、一安心 ちなみに、my.cnfに設定する場合 [mysqld]
expire_logs_days=30 とするらしいです。
|
|
|
|
|
2016 04,21 04：59 |
|
|
MySQLのログって肥大化するので、ローテートをするのだけど
意外と上手くいかない なので、ここにローテートの内容を残す vi /etc/logrotate.d/mysqld (名前は適当に。既に存在しているファイルがあるかもしれない）
/var/log/mysqld/*.log {
create 640 mysql mysql
notifempty
daily
rotate 7
missingok
postrotate
if test -x /usr/bin/mysqladmin && /usr/bin/mysqladmin ping &>/dev/null
then
/usr/bin/mysqladmin -u hogehoge flush-logs
fi
endscript
} # which mysqladmin でmysqladmin のパスは、環境ごとに確認 -u hogehogeとしたけど、もう少しセキュリティを考えると、 アカウントを別ファイルにするのがいいのでしょう # vi /root/.my.cnf
[mysqladmin]
password = xxxxxxxx
user= root
# chmod 600 /root/.my.cnf
とした場合 /usr/bin/mysqladmin --defaults-extra-file=/root/.my.cnf flush-logs としても良さそう # logrotate -dv /etc/logrotate.d/mysqld でエラーがないことを確認 あとはローテートされていることを楽しみにして待つ。みたいな
|
|
| 忍者ブログ [PR] |
