MySQLお勉強メモ(MyISAMストレージエンジン) | きぬろぐ
特徴 ファイル形式 table_name.frm : メタデータ table_name.MYD : 実データ table_name.MYI : インデックス ヘッダ インデックスブロック ロック テーブル単位。ロック方式は以下。 READ LOCAL(SELECT/INSERT OK。UPDATE/DELETE NG) READ(SELECT OK。INSERT/UPDATE/DELETE NG) WRITE(すべてNG) Concurrent INSERT mysql > SET GLOBAL concurrent_insert = xで制御 0 : 利用しない 1 : MYDファイルに穴がない場合にSELECT中にINSERT可能 2 : データの最後にAPPENDする。SELECT中にINSERT可能 そのほか ロックがかかっている時に他SQL(SELECT/UPDATE等)が入って
MySQLのデータファイルが壊れたら(MyISAM) - ブログリトライ
[ERROR] Got error 134 when reading table './データベース名/テーブル名' こんなエラーが出てたらデータファイルが破損してるので、myisamchkコマンドで修復する。 myisamchk --silent --force --fast --update-state -O key_buffer=64M \ -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \ /path/to/datadir/*/*.MYI こんな感じでエラーのあるデータファイルを修復してくれる。それでもおかしな場合は myisamchk -o /path/to/datadir/*/*.MYI これでより高度な修復ができる。 もちろんMySQLを止めて作業すること。
MyISAM の Cardinality が飛んだ - TrashSUITE
ここまでくると逆に清々しいよね，というくらい派手に飛んだ．そして原因はわからない 環境 root@alice% cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.04 DISTRIB_CODENAME=hardy DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS" root@alice% uname -a Linux alice.trashsuite.org 2.6.24-24-xen #1 SMP Wed Apr 15 18:53:17 UTC 2009 i686 GNU/Linux root@alice% mysqld --version mysqld Ver 5.0.51a-3ubuntu5.4-log for debian-linux-gnu on i486 ((Ubuntu)) 経緯 my
[ソフトウェア] (いまさら)MyISAMのマルチカラムインデックス構造 カイハツニッキ(2008-01-24)
_ [ソフトウェア] (いまさら)MyISAMのマルチカラムインデックス構造 MyISAM(というかMySQL)といえばマルチカラムインデックスです(インデックス1つしか使えないしー)。マルチカラムインデックスのメリットと制限については複合インデックスに書いてあって、その構造については インデックス化されたカラムの値を連結することによって生成された値が含まれ、ソート化された配列と見なすことができます と書いてあります。となると多分、 mysql> SHOW CREATE TABLE foo\G *************************** 1. row *************************** Table: foo Create Table: CREATE TABLE `foo` ( `a` int(11) default NULL, `b` int(11) def
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
MySQL :: MySQL 4.1 リファレンスマニュアル :: 4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ
Section Navigation [Toggle] 4.5 障害の予防とリカバリ4.5.1 データベースのバックアップ 4.5.2 BACKUP TABLE 構文 4.5.3 RESTORE TABLE 構文 4.5.4 CHECK TABLE 構文 4.5.5 REPAIR TABLE 構文 4.5.6 myisamchk を使用したテーブルの保守とクラッシュのリカバリ 4.5.6.1 myisamchk 起動構文 4.5.6.2 myisamchk の一般的なオプション 4.5.6.3 myisamchk のチェックオプション 4.5.6.4 myisamchk の修復オプション 4.5.6.5 myisamchk のその他のオプション 4.5.6.6 myisamchk のメモリ使用 4.5.6.7 myisamchk を使用したクラッシュのリカバリ 4.5.6.8 テ
[MySQL] MySQLのデータベースが壊れたみたいです | 技術雑記
MySQL 5.1 リファレンスマニュアル :: 4.9.4 テーブル保守とクラッシュ リカバリ とある開発環境(xenのdomainUです)で開発してて、思わずDisk FULL！ ふと気がつくとapacheのログにエラーが大量に…。 [error] Error executing class callback in teardown stage: DBD::mysql::db do failed: Table './sample/table' is marked as crashed and should be repaired at /usr/share/perl5/CGI/Session/MySQL.pm line 83.\n\t(in cleanup) DBD::mysql::db do failed: Table './sample/table' is marked as cr
![[MySQL] MySQLのデータベースが壊れたみたいです | 技術雑記](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d0465fb77e6b07037ca3416f24edac04f5a5427/height=288;version=1;width=512/http%3A%2F%2Fmozshot.nemui.org%2Fshot%3Fhttp%3A%2F%2Fdev.mysql.com%2Fdoc%2Frefman%2F5.1%2Fja%2Ftable-maintenance.html)
圧縮MyISAMテーブルで商品マスターを運用する方法
商品マスターのように参照専門で利用するテーブルならば、圧縮MyISAMが非常に適していることが多い。その方が容量が小さくなるし、ディスクI/Oが減るので高速化が期待出来るからだ。圧縮MyISAMを利用する時の問題点は、MySQLサーバ起動中にテーブルの圧縮を行えない点であろう。（正確には行えなくもないが、操作は慎重を期する必要がある。）また、圧縮MyISAMテーブルはひとたび圧縮してしまった後は、更新を加えることが出来ないのだが、如何に商品マスターといえども、一日に一度程度の頻度で更新をかけないといけないかも知れないので、これまた問題である。圧縮MyISAMテーブルを用いた運用は利点がある一方で、このような問題があるため難しい。そこで、今日は圧縮MyISAMテーブルで商品マスターを運用する方法について紹介しよう。 商品マスター作成用のMySQLサーバを用意する。オンライントランザクションを
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
MySQLによるデータウェアハウス構築
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のWangです。 データウェアハウス（以下DWH）という言葉になじみのない方は検索していただいたほうがよいかもしれません。 検索するのがめんどい、という方は、かみ砕いた表現ができなくて恐縮ですが、 基幹系システムから抽出したデータを目的をもって再構成し、 使用可能な状態に保管されたデータの集合体、とお考えください。 オークションでは、具体的には出品、入札、落札などのトランザクションデータや、 それをいろいろな単位で集計したデータなどが該当します。 ここでいう単位というのはたとえば、日ごと、週ごと、月ごとや、以前の記事でも紹介されている カテゴリといったものになります。 こういったデータは、運用、運営、
[ThinkIT] 第2回：MyISAMとInnoDB (1/3)
今回は、MySQLのストレージエンジンの中でも特に有名な「MyISAM」と「InnoDB」の2つを取り上げます。MyISAMはMySQLのデフォルトストレージエンジンで、ストレージエンジンを指定せずにテーブルを作成するとMyISAMが選択されます。もう一方のInnoDBエンジンは、MySQLに豊富なトランザクション機能を提供するストレージエンジンとして有名です。 まずはそれぞれのテーブルファイルの構造について解説し、最後にInnoDBのトランザクションについて解説します。 各ストレージエンジンのファイル構造を説明する前に、前知識としてMySQLのディレクトリ構造について説明します。 MySQLのデータベースディレクトリには、バイナリログと呼ぶデータベースの更新情報を格納するファイルと、2つのサブディレクトリが存在します（図1）。 「mysql」ディレクトリには権限テーブルと呼ばれるMySQ
mysqldump と repair with keycache - いちいの日記
でかいテーブルをdumpしてimportしなおすときに、alter enable keysで "repair with keycache" に悩まされてたんですが、MySQL Forums見てたらそのものズバリなのを見つけたのでメモ。 http://forums.mysql.com/read.php?35,155467,166902 ご存知の方には当たりまえな感じですが、自分はそもそも repair by sorting と repair with keycache の2通りのメッセージが出し分けられていること自体に気づいてませんでした。 mysqldump mysqldumpをつかってデータベースを(そのままimportに使える)SQL文に吐き出します。 % mysqldump -uuser -ppass -hhost hoge > hoge.sql このときhoge.sqlの中身はこん
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
