Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

こんばんは。 笹亀です。 弊社では、MySQLを使用しているシステムが多くあります。 みなさんも、MySQLは頻繁に使用しているのではないでしょうか。 私が特にMySQLなどのRDBMS(Relational Database Management System)を使用するときに気をつけていることが、SQLを記述するということです。 私は「どのようにSQLを発行すればよいか」という点を気にしながら、コーディングをすることが多いです。 自分が経験したことで、SQLの書き方ひとつでも大きな問題になったこともあり、 SQLの書き方には知恵を絞って、いかに効率がよいSQLを記述するかということを心がけるようになりました。 今回はSQLの結果では同じ結果を返す、3種類の結合の速度を比べてみました。 今回はサンプルテーブルとして、下記の2つのテーブルを使用します mysql> desc user_m;
今まで mysql... 系を使用していましたが、PHP5.5以降は非推奨となり、将来的には削除される予定らしいので、PDOの使用に変更しようと思い、まとめてみました。 プリペアドステートメントでINSERTすると安全に値を渡せるとか、結構便利みたい。 Manualとか色々読んだけど、分かりにくい言葉が多かったので、自分なりに解釈を書いています。 PDOとかプリペアドステートメントの説明 こっちのページに詳しく書いています。 言葉の意味分からんわー。みたいな時は是非読んでみてください。 PDOでMySQLを色々やる。 まずメソッドや引数をちょっとまとめました。 今後増やしていこうと思っています。 メソッドや引数 内容
はじめに ありきたりなメモなのですが久しぶりの息抜きメモ。 mysqlのauto_incrementについて、 下記みたいなことがちょくちょくありますがその度に忘れてるのでメモ。 auto_incrementの値知るのどうやんだっけなー deleteしちゃったからauto_incrementの値変えなきゃなー deleteしすぎて歯抜けになりすぎたから連番揃えてauto_incrementの値も変えてキレイにしたいなー あじぇんだ auto_incrementの設定を確認する auto_increment値を確認する auto_increment値を更新する auto_increment使ってるテーブルの歯抜けの連番を整理する auto_increment属性のカラムに0(ZERO)入れるとどうなるか 4と5はauto_incrementそのものというよりは auto_incrementテ
MySQLだとDELETEがとても重いです。10000件程度なら余裕ですが、100000件、1000000件にもなると手のつけようがないレベルです。その間MyISAMだとテーブルロックがかかるし、DELETEしすぎると今度は断片化してOPTIMIZE TABLEでもしないと速度低下が始まります。 OPTIMIZE TABLEやALTER TABLEはものすごく時間がかかることがあるんですよね。今回DELETEしようとしたテーブルはWebでの表示に必須の部分でして、どうせならWebをできるだけ落とさずにやってみるかという挑戦でした。 今回DELETEするのは27000000件くらいです。無理です。 処理を一度にできないと踏んだので、DELETEを増加量より多いLIMITで走らせればだんだんと減っていくのではないかと考え、実行。 ごり押しでLIMIT指定で絞ったDELETEを走らせた結果900
insert 遅い原因 insertする際に、対象テーブルのインデックスブロックを読み込んで、 更新かけるので、インデックスサイズが大きいと、パフォーマンスが落ちる。 なので、テーブルのデータ増加が原因で、I/Oが発生し、徐々に遅くなっていく。 インメモリで処理できなくなると、突如としてパフォーマンスに影響が出やすい 対策 テーブルサイズをできるだけ小さく(レコード長を小さく) インデックスサイズを小さくすること(無闇にインデックス貼らない) パーティショニング(DB間のテーブル移動) 不要データ削除 16KB毎(たぶん)のブロック単位でデータを保持しているので、 断片化されたデータを削除しても効果が薄いです。 Auto Incrementの場合は、ID1〜10000等をまとめて削除する等であれば、効果が期待できます。 ただし、ただし次のインサート以降、空いたブロックを活用するので積極的に
トリガーの中で対象のテーブルに追加や更新するデータのカラムの値を参照する(OLD.col_name, NEW.col_name) 作成したトリガーは対象となるテーブルにデータを追加したりデータを更新したりした時に起動しますが、トリガーが起動したときに実行される SQL 文の中で、対象となるテーブルに追加や更新されるデータの値を参照して利用することができます。ここでは MySQL でトリガーの中でテーブルに追加や更新されるデータを参照する方法について解説します。 トリガーの中で追加や削除されるデータのカラムの値を参照する トリガーは対象のテーブルにデータの追加や更新といった操作が行われた時に起動しますが、トリガーの中で対象テーブルの更新前のデータや更新後のデータを参照したい場合があります。例えばトリガーの対象のテーブルに追加されたデータを他のテーブルにも同じように追加したい場合や、データを更
CREATE TRIGGER trigger_name { BEFORE | AFTER } { INSERT | UPDATE | DELETE } ON tbl_name FOR EACH ROW trigger_body トリガーは対象となるテーブル( tbl_name )で指定した操作があった場合に実行する SQL 文( trigger_body のところで記述)を定義しておくものです。トリガーが起動する操作の種類は INSERT 、 UPDATE 、 DELETE の3種類があります。 INSERT トリガーはテーブルに行が追加される前または後に設定した SQL 文が実行されます。例えばテーブルに対して INSERT 文や REPLACE 文、 LOAD DATA 文が実行された時です。 UPDATE トリガーはテーブルのデータが更新される前または後に設定した SQL 文が実行さ
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く