MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
nabokov7; rehash : O/Rマッパーはなぜ悪か・2
December 07, 201215:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か・2 前回、「SQLには○○が足りない！よろしくない！そこで...O/Rマッパー！」みたいなスライドを見た気がして、ひどいO/Rマッパーにさんざん苦しめられた記憶がフラッシュバックのように襲ってきて、 フザケンナ！お前らO/Rマッパー大好き族のせいでこっちは！こっちは...どんだけ苦労したか! ってかーっとなって記事書いたら、 「は？最近のO/Rマッパーはそんなアホじゃないし？w」「あ，はい。そうだったんですねー」 みたいな感じで瞬殺されて残念な感じになったw。いや、でもなんか違う、この気持ち、なんだろう。みんなにも伝えたい。なのでもうちょっと書く。 自分のO/Rマッパー不信にはいくつかのレイヤーがあって、いまだにそれがうまく整理できないんだけど、たぶん 1. 現実レベルの問
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 >=
mysqlで双方向(マルチマスタ)レプリケーション - end0tknr's kipple - web写経開発
前回までに1台の複数のmysqlを起動する方法を紹介しましたが、今回は、それらで双方向(マルチマスタ)レプリケーションを行う方法を紹介します。 my.cnf と my2.cnf 私のcolinux環境ではオプションファイルを切り替えることで、複数のmysqlを起動していますが、以降では次のように表記します。 オプションファイル ここでの表記 /etc/my.cnf my.cnf /etc/my2.cnf my2.cnf レプリケーション用ユーザの追加 mysqlではslaveからmasterを参照する際、レプリケーション用のユーザを使用するようです。そこで、my.cnf, my2.cnf のそれぞれに「GRANT REPLICATION SLAVE」を実行して下さい。 my.cnf> GRANT REPLICATION SLAVE ON *.* TO repl@localhost IDEN
mysqlのログファイルのサイズを変更する - よかろうもん！
バイナリデータを格納するために、BLOB型やその拡張のMEDIUMBLOB型を利用するシーンが時折あるかと思います。 BLOB型を利用していて、サイズの大きなデータをDBに格納しようとすると、MySQLのログに以下のようなエラーログが出力されることがあります。 100906 00:00:00 InnoDB: ERROR: the age of the last checkpoint is 9440228, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB:
innoDBの最初の挙動 - 見果てぬ夢
バックアップに関わる実験の１つ。 現在僕のPCには、MySQL6が入っている。恥ずかしながらほとんど使われていないので、innoDBのibdataファイルの初期化とib_logfile0とib_logfile1がどうなるかを知ろうと思った。 ibdataにはinnoDBテーブルのデータとインデックスデータが、全てのデータベースから入れられている。これはテーブルスペースとして一定量確保されている。容量が足りなくなると、さらに一定量追加される仕組みのようだ。データの消去をしても残るらしいので、ファイルサイズは自然に小さくなることはない。このファイルサイズの大きさを適正にしたい場合は、mysqldumpをして、必要ファイルを削除してから、リストアしないといけない。 まずはmysqldumpをする。が、僕のデータベースにはテスト用だけなのでバックアップをとらなかった。mysql用のデータを保存して
MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
InnoDB におけるカラムの格納 - kazuhoのメモ置き場
カラムサイズが768バイトを超えると16KB単位になるってのは重要。 Question: How much space InnoDB allocates for each blob outside of the page? HT: For each column that InnoDB needs to store ‘externally’, it allocates whole 16 kB pages. That will cause a lot of waste of space if the fields are less that 16 kB. The ‘zip’ source code tree by Marko has removed most of the 768 byte local storage in the record. In that source code tr
MySQLメモ (Nega Diary)
Nega Diary 人生とは記憶の蓄積。日々の記録とは、日々の行動・思考を書き記し、自分の存在を確かめる行為。 ちょっと古いけど、スラドの記事。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならない SHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通 rnd と rnd_next の割合 Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意 Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果など Max_used_connections: 最大同時接続数 Not_flushed_*
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とある診断員とSQLインジェクション
MySQLはそれほど速くないし、PostgreSQLはそれほど遅くない in 2010