MySQLで処理に長時間かかっている複数クエリをまとめて殺す方法 | Basicinc Enjoy Hacking!
あまりにも処理に時間がかかるようなSQLを実行してしまい、MySQLがうんともすんとも言わなくなってしまうような状況、よくありますよね。っていうか、まぁそんな状況あってはならないんですが、時たまあります。そんな時、問題となっているクエリの処理を止めたいわけです。 特定のクエリを止める方法 MySQLで実行中のクエリ一覧を見て、SQLを強制終了する方法 こちらを見てもらえればやり方は分かります。単純にMySQLに入って、show processlist;で問題のあるクエリを発見し、プロセスIDを kill するだけ。とても簡単。 複数のクエリを一括で止める方法 今回は問題のあるクエリが100個あったらどうする…？的なのを解決するエントリーです。まぁ、問題あるクエリ100個ある状況は、アプリ的に問題あるんじゃね？っていうレベルですが。 1個ずつプロセスIDをコピペして…なんてやってられないです
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
ウノウラボ Unoh Labs: RDBで階層構造を扱うには？
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
