MySQL processlist phrase book
For your convenience, a short phrase book, starting with explanation of process states where MySQL is mostly working to look up data from tables: “Sending data” – reading data from tables (or looking it up) “Copying to tmp table” – reading data from tables (or looking it up) “Copying to tmp table on disk” – query needs a rewrite “statistics” – looking up data from tables “Sorting result” – reading
Webyog » “MySQL server has gone away” Part 2: session timeout.
This is the second and last article of a small series on reasons for the error message: “MySQL server has gone away”. The first appeared here describing that “if a client sends a SQL-statement longer than the server max_allowed_packet setting, the server will simply disconnect the client.” This article will deal with another common reason: the connection has timed out. This is in principle not dif
Webyog » “MySQL server has gone away” Part 1: max_allowed_packet.
Most MySQL users have tried getting this rather cryptic error message: “MySQL server has gone away”. The MySQL documentation describes lots of possible reasons for this here: http://dev.mysql.com/doc/refman/5.1/en/gone-away.html However this page is of little help for most users, I think. Dozens of reasons are listed, but except for the trivial ones (like physical connection was lost, the MySQL se
WebアプリのDBスキーマレス化がRubyにぴったりな件 - Tous Les Jours 攻防記
という題で、RubyKansai#37で発表させていただきました 内容は、WebアプリケーションのDBのスキーマレス化について。 スキーマレスなDBアクセスのための、拙作DBインターフェースライブラリ「SimpleResource」の紹介も合わせて盛り込みました。SimpleResourceは、スキーマレスなデータを保存するためのKVS DBインターフェースライブラリで、Rubyで書かれています。レコード単位のロック機構、インデックス機能等を備えている他、ActiveRecordに近い使い勝手で利用することができます。ストレージには現在MySQLとTokyoTyrantにのみ対応しています。（FriendFeedの同様の試みもかなり参考になりました。詳細はまた後日にエントリで上げたいと思ってます） SimpleResourceは、GitHub上で開発を続けていくつもりです。 http://
新書籍「Linux-DBシステム構築/運用入門」
Linux上で「高速で、落ちない」DBサーバーを構築するための技術解説をした書籍を出版します。タイトルはストレートに「Linux-DBシステム構築/運用入門」です。 9月17日発売ですが、ジュンク堂など一部の書店ではすでに入荷しているそうなので、見かけたらぜひ読んでみてください。章構成は以下の通りです。 第1章 論理ボリュームマネージャ(LVM)を活用する 第2章 Heartbeatによるクラスタ環境の構築 第3章 DRBDによるネットワークミラーリング(前編) 第4章 DRBDによるネットワークミラーリング(後編) 第5章 高可用DBサーバーの構築 第6章 現場で使われる高可用構成 第7章 DBサーバーのパフォーマンス概論 第8章 インデックスのチューニング(前編) 第9章 インデックスのチューニング(後編) 第10章 DBサーバーのハードウェア選定 第11章 SSDの効果とアプリケーシ
仙石浩明の日記: 文字化けしていなくても MySQL 内の文字コードが正しくない場合がある
MySQL 5 からテーブルごとに文字列のエンコーディングを指定できるようになった (「そんなことは知ってるYO!」という人も多いと思うので、 そういう人は「これからが本題」 の部分まで読み飛ばして欲しい)。 例えばテーブルを作るときに、 mysql> CREATE DATABASE test; Query OK, 1 row affected (0.05 sec) mysql> USE test Database changed mysql> CREATE TABLE user ( name VARCHAR(255) ) CHARSET=utf8; Query OK, 0 rows affected (0.05 sec) などと 「CHARSET=utf8」 を指定すれば、 文字列を UTF-8 エンコーディングで格納する。 「CHARSET」 すなわち 「文字集合」 と、 エンコーディ
オラクル、サン買収後の事業支援を保証--MySQLについては明言せず
Oracleは現地時間9月10日、Wall Street Journal（WSJ）の欧州版トップページ広告において、Sun Microsystemsの顧客向けにメッセージを掲載した。 同広告では、今後もSunのハードウェアならびに「Solaris」ソフトウェア向けに多くの資金を投入していく方針が明示されているものの、特に「MySQL」については言及されていない。これは欧州の規制当局との関係緩和を狙って、意図的に省略されたのであろうか？それとも、何かOracleの意図を示したものなのであろうか？ 一方、Oracleの最高経営責任者（CEO）であるLarry Ellison氏は、Sunのシェアを奪って成長を狙うIBMに対して「われわれは勝利を目指して進んでいる。IBMよ、われわれはハードウェア事業で競争を繰り広げられることを楽しみにしている」との警告を発した。 Sunの事業は、Oracleによ
SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin - SH2の日記
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (2009/03/25) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (本記事) MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケ
MySQL
HeatWave Use automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse scale analytics. Get faster insights from all your data with unmatched performance and deploy apps in your choice of cloud providers. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical support to achieve
コスいチューニング - フツーな日常
全く本質的でなく効果も小さいものばかりだけど、最後のひと絞りにどうぞ。 Hardware HT無効 今時サーバでNetBurstもないだろうけど、使っているなら切った方が速い。並列実行度が高くなるには違いないが、spin lockとHTは相性がよろしくないし、そもそもNetBurstのHTは速くなる局面が少なすぎる。いっぱいプロセッサが見えるのは気持ちいいが、実効性能を考えると無効の方が速い。 RAID1+0 ブロックサイズは大きめで(256KBとか)にする。"1つのレコードの大きさ ＜＝ RIADのブロックサイズ"である状態だと、RAIDを構成する複数のディスクのうち1個へのリクエストで処理が完結するので具合が良い。逆に"1つのレコードの大きさ ＞ RAIDのブロックサイズ"であると、1レコードの読み出しにも2個のディスクがその処理にかかり切りになってしまう。HDDの毎秒の処理回数は上限
mysql:15009
From: Mikiya Okuno <Mikiya Okuno <Mikiya.Okuno@xxxxxxxxxx>> Date: Thu, 03 Sep 2009 22:35:56 +0900 Subject: [mysql 15009] Re: 検索処理を早くするには？ 岡田様、 こんばんは。 On 03/09/2009, at 8:35 PM, Takayuki Okada wrote: > お世話になります。 > 岡田と申します。 > > 非常に漠然とした質問になり、すみません。 > > DB2からMySQLへ移行し、性能を測ってみたところ、 > 全件検索が非常に遅くなりました。 > > explainで確認すると、一応、PKは使用しているようですが、 > 件数が多くなると、やはり遅くなります。 > > 何かよいチューニング方法はないでしょうか？ > インデックスは条件句が複数とな
MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
全テーブルの統計情報をサイズ順に一覧表示する
MySQLにおいて、テーブルサイズやインデックスサイズ、レコード数、平均レコード長などの統計情報を知る上でshow table statusは定番です。ただ雑多な表示項目も多いので、たくさんのテーブルの統計を見る場合、必要な情報だけを返したいことは多いです。また全テーブルのうち、どのテーブルが一番大きいのかを知りたいとか、サイズが多い順に一覧表示したいとか、一目で分かるような情報がほしいことも多いです。 こういうときはinformation_schema.tablesを使うと便利です。以下の例では、appデータベースの全テーブルについて、「テーブルサイズ+インデックスサイズ」の大きい順に、ストレージエンジン、レコード数、平均レコード長、テーブルサイズ(MB)、インデックスサイズ(MB)などを返しています。 use app; select table_name, engine, table_
DBチューニングではディスクI/O性能を注視する
DBチューニングにおいて、気を配るべきところは数多くありますが、中でも真っ先に見るべきところはディスクI/Oでしょう。なぜかというと、メモリアクセスに比べてHDDの方が圧倒的に遅く、最もパフォーマンス阻害要因になりやすいためです。ディスクI/Oネックの解決方法を探っていくと、「テーブル/インデックス設計やSQL文の見直し」に行き着くこともまた多いです。これらが不適切だと、結果として大量のレコードをアクセスすることになり、ディスクI/Oが多く発生してしまうためです。根本的な原因はディスクI/Oにあります(CPUネックになることもありますが、その例は別の機会に取り上げます)。 ディスクI/Oには大きく分けてシーケンシャルアクセスとランダムアクセスの2種類のアクセスパターンがありますが、RDBMSではインデックスアクセスが主体となるため、ルート→ブランチ→リーフ→実レコードという経路でのランダム
mysql 5.1 のパーティショニングを試す - end0tknr's kipple - web写経開発
postgresで巨大レコード数のtableを扱うなら、パーティショニング - end0tknr's kipple - web写経開発 以前、postgresのパーティショニングには触れましたが、今回はmysql5.1.34のパーティショニングを試したいと思います。 have_partitioning=NOの場合、再make http://dev.mysql.com/doc/refman/5.1/ja/partitioning-overview.html パーティショニングの可否は、SHOW VARIABLES で確認できますが、have_partitioning=NO の場合、configureのオプションに --with-plugins=partition を追加して、再makeする必要があります。 mysql> SHOW VARIABLES LIKE '%PARTITION%'; +
PARTITION使ってみた - いちいの日記
先日「MRG_MyISAM使ってる人なんていねーよPARTITIONつかえ、PARTITION」というお告げをもらったので、ちょっとだけpartition使ってみることにしました。といってもMySQLを5.1にするところから始めないといけないので、いろいろ面倒なこともありつつ。 ただ、根本的に使用目的がちがう部分もあるので、単純にMRG_MyISAMから乗り換えってわけにもいかないでしょう。特に、既存のテーブルを気楽にmergeできるメリットは、あらかじめ分割ストラテジを決める必要があるpartitionでは実現できないものです。 とりあえず今日は使ってみた感触ですが、MyISAMのときにpackがどうなるのかとか、いつか調べたいと思います。 mysql5.1導入 すでにある5.0運用のdatadirにそのままかぶせる形で5.1に上げることにしました。 最初にハマったのは basedir
Adminer - Database management in a single PHP file
Adminer (formerly phpMinAdmin) is a full-featured database management tool written in PHP. Conversely to phpMyAdmin, it consist of a single file ready to deploy to the target server. Adminer is available for MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Oracle, Elasticsearch, MongoDB and others via plugin. Features, Requirements, Skins, References Why is Adminer better than phpMyAdmin? Replace phpMy
MySQL, Linux, and Thread Caching (by Jeremy Zawodny)
Wow, it's been a busy week. I was totally swamped for several days dealing with the remember.yahoo.com MySQL servers and related stuff. And then I used a day or two to recover (sleep, shower, etc). Anyway, I made some interesting discoveries along the way. The most surprising one had to do with thread caching on Linux when you have a busy MySQL server--busy in a particular way, mind you. You see,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー
Google Code Archive - Long-term storage for Google Code Project Hosting.