タグ

ブックマーク / nippondanji.blogspot.com (46)

  • MySQLのZero Dateへの対処法

    MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー

    MySQLのZero Dateへの対処法
    hiro_y
    hiro_y 2018/05/14
  • MySQL User Conference Tokyo 2015で発表しました:MySQL 5.7におけるオプティマイザの改良点

    昨日、告知させていただいたMySQL User Conference Tokyo 2015で登壇したので、その時の資料を公開した。MySQL 5.7の機能は全部ひとつのスライドで紹介しようとすると、多すぎて私にはコンパクトにまとめるだけの技量は無いため、今回はオプティマイザだけの紹介にした。興味のある方はご覧頂きたい。 そういえばすっかり忘れてしまっていたのだが、MySQL 5.7が登場した!!というブログエントリを書くのを忘れていた。もしかすると読者の皆さんの中には、MySQL 5.7が正式リリースされたことをご存じない方もいらっしゃるかも知れない。遅くなって申し訳ないが、MySQL 5.7は、バージョン5.7.9をもって正式版となっている。5.7.9は約2ヶ月前にリリースされた。ついでに言うと、バグ修正を含んだ5.7.10が既に出ている。 MySQL 5.7はまさにモンスターだ!!!と

    MySQL User Conference Tokyo 2015で発表しました:MySQL 5.7におけるオプティマイザの改良点
    hiro_y
    hiro_y 2015/12/23
  • MySQLレプリケーションの運用が劇的変化!!GTIDについて仕組みから理解する

    メリークリスマス!!やあ、良い子のみんな!!サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ!! というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID(Global Transaction ID)である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ

    MySQLレプリケーションの運用が劇的変化!!GTIDについて仕組みから理解する
    hiro_y
    hiro_y 2014/12/26
  • まだMySQL 5.5で消耗してるの?MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法

    MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン!!と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり(つまりクラッシュ)しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。(REDOやUNDOするアレのことだ。稿では面倒臭い・・・ではなかった、題ではないた

    まだMySQL 5.5で消耗してるの?MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
    hiro_y
    hiro_y 2014/12/16
  • リレーショナルモデルのドメイン設計についての議論

    リレーショナルモデルを実践するには、ドメイン(≒データ型)を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性(≒カラム)に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

    リレーショナルモデルのドメイン設計についての議論
    hiro_y
    hiro_y 2013/12/14
  • SQLインジェクション対策に正解はない

    最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ

    SQLインジェクション対策に正解はない
    hiro_y
    hiro_y 2013/12/14
  • 隙がなくなったMySQL Cluster 7.3登場!!これで勝つる。

    MySQL Cluster 7.3の正式版がリリースされた。このバージョンで追加された新機能は少ない。だが、これまでにリリースされたMySQL Clusterのバージョンの中で、この7.3こそが最も重要なバージョンである!と私は考えている。新機能は少ないが非常に重要なものが詰まっているからだ。今日はMySQL Cluster 7.3の新機能について見てみよう。 外部キー制約、来たる!何を差し置いてもまず重要なのが、外部キー制約である。長年InnoDBでは使えるが、MySQL Cluster(NDBストレージエンジン)には実装されていなかった。外部キー制約が使えないという理由でMySQL Clusterを採用しなかったという人も多いだろう。 だが、それはこれまでの話だ。MySQL Cluster 7.3なら外部キー制約が使える!! メジャーどころのRDBMSなら当たり前のように搭載されている

    隙がなくなったMySQL Cluster 7.3登場!!これで勝つる。
    hiro_y
    hiro_y 2013/06/20
  • MySQL 5.6正式リリース!! #mysql56

    待望のMySQL 5.6が正式にリリースされた。正式版の最初のバージョンは5.6.10である。コミュニティ版(MySQL Community Server)は下記のページからダウンロードできるので、ぜひ今すぐダウンロードして頂きたい。 MySQL Downloads MySQL 5.6のリリースにあわせて、GUIツールであるMySQL Workbenchやドライバも新しいバージョンがリリースされており、MySQL 5.6対応となっている。それらの周辺ソフトウェアもチェックして頂けると幸いである。 新機能について正式版の機能はリリース候補版の頃から特に変更はない。(リリース候補版まで到達したということは、正式版の機能セットは固まったということであり、大きな機能の変更はないことを意味するからだ。)なので新機能については、リリース候補版が出たときに書いたエントリを参照して頂きたい。 漢(オトコ)

    MySQL 5.6正式リリース!! #mysql56
    hiro_y
    hiro_y 2013/02/06
  • 開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!

    米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC(リリース候補版)が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている!正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは?などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか?と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB

    開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!
    hiro_y
    hiro_y 2012/10/01
  • MySQLにおけるレプリケーション遅延の傾向と対策

    レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということをエントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ

    MySQLにおけるレプリケーション遅延の傾向と対策
    hiro_y
    hiro_y 2011/12/27
  • lessでソースコードに色をつける

    シェルの操作中「テキストファイルをちょこっと覗きたいな」と思ったときに抜群に便利なlessコマンドであるが、普段綺麗に色付けされたソースコードを見慣れていると、モノクロのソースコードの見づらさに愕然としてしまう。結局lessを終了して他のエディタで開きなおすことになるのだが、lessでソースコードに色付け(シンタックスハイライト)できれば便利なのになーっ!と思ったことはないだろうか。そう、あるんです!lessでシンタックスハイライトする方法はあるんです!というわけで、今日はその方法を紹介しよう。 GNU Source-highlight結論から言うと、今日紹介する方法はGNU Source-highlightを使う。GNU Source-highlightを使えばイッパツだ。なのでまずGNU Source-highlightをインストールしよう。UbuntuやFedoraならリポジトリにあ

    lessでソースコードに色をつける
    hiro_y
    hiro_y 2011/11/10
    lessでシンタックスハイライト、GNU Source-highlight使う
  • MySQL 5.6登場!!新機能速攻レビュー

    現在、米国で行われているMySQL Conference & Expoにあわせて、新しい開発版であるMySQL 5.6が発表された。MySQL 5.5における新機能もかなりのものだったが、MySQL 5.6の進化は質・量ともに勝とも劣らない内容となっている。そこで、今日は簡単に、MySQL 5.6で追加された新機能の概要について見てみよう。開発版なので利用にあたっては十分な注意が必要(予期なく予定が変更される可能性あり)だが、次期正式版のリリースに向けて是非試してみて欲しい。 InnoDB関連MySQL 5.5で大幅な進化を遂げたInnoDBだが、その勢いはまったく衰えることを知らない。性能の強化だけでなく、痒いところに手が届く便利な機能が追加されている。 ダーティページのフラッシュをするスレッドが独立した。以前はマスタースレッド内でフラッシュが行われていたが、スレッドが独立したことによっ

    MySQL 5.6登場!!新機能速攻レビュー
    hiro_y
    hiro_y 2011/04/16
    MySQL 5.6の新機能。memcached互換プロトコルの追加など
  • MySQL 5.5新機能徹底解説

    今年も残すところあとわずかとなった。2010年もIT業界にとっては変化の多い一年だったが、皆さんにとっては良い年だっただろうか?既に何度かMySQL 5.5の新機能については取り上げたが、ついに正式版がリリースされたということでここで改めて新機能を解説し、今年最後のエントリを締めくくろうと思う。 MySQL 5.5にはこれでもかっ!というぐらい新機能が追加されている。しかもいずれもナイスなものばかりだ。一般的には、ソフトウェアに新機能が追加されると重くなったり安定性が低下する事例が後を絶たないのだが、MySQL 5.5に関してはそのようなことは全くないので安心して利用して頂きたい! InnoDBの大幅な改善種々ある改善点の中でも特に目をひくのがInnoDBストレージエンジンへの改良だ。実は、InnoDBMySQL 5.1が最初にリリースされたときから、2回アップデートが行われている。My

    MySQL 5.5新機能徹底解説
    hiro_y
    hiro_y 2011/01/02
    MySQL 5.5の新機能
  • HA化機能を手に入れたSPIDERストレージエンジンにはもはや死角はなかった。

    ブログでも何度か取り上げたことのあるあのSPIDERストレージエンジンがさらにパワーアップして便利になった!8月にリリースされたバージョン2.22では次の2つの強化が行われている。 HA機能の追加(データノードの冗長化) LinuxおよびWindows用ビルド済みMySQLパッケージの配布 インストールが簡単になった!前回SPIDERストレージエンジンを紹介したときには、ソースコードからコンパイルする必要があり、なおかつMySQL体にパッチを適用しなければならず、利用するまでの敷居が高かったように思う。しかし、バージョン2.22よりSPIDERを含んだビルド済みバイナリが提供されたことにより、SPIDERを利用する手間はぐっと少なくなった。しかもこのビルド済みのバイナリにはSPIDERだけでなく各種パッチと、さらにはVPストレージエンジンまで含まれているという気の利きようだ。コンパイル

    HA化機能を手に入れたSPIDERストレージエンジンにはもはや死角はなかった。
    hiro_y
    hiro_y 2010/10/24
    SPIDERストレージエンジンのHA機能を紹介
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
    hiro_y
    hiro_y 2010/10/05
    countの高速化するのにセカンダリインデックスの利用を検討する
  • 知って得するInnoDBセカンダリインデックス活用術!

    InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

    知って得するInnoDBセカンダリインデックス活用術!
    hiro_y
    hiro_y 2010/10/05
    「InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。」「セカンダリインデックスのリーフノードには主キーの値が含まれている」
  • 大人のためのInnoDBテーブルとの正しい付き合い方。

    InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか?」というものがある。InnoDBMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

    大人のためのInnoDBテーブルとの正しい付き合い方。
    hiro_y
    hiro_y 2010/09/27
    InnoDBの扱い方。データの扱われ方など。analyze/optimizeの言及あり。
  • 残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ!!

    なんて幸運なことなんだろう。 実は最近、個人的にサーバーマシンを借りるという機会があった。そのマシンに搭載されているCPUコア数は合計48である!大事なのでもう一度いう。日語でいう。48CPUコアだ!一昔前なら数千万円もしたスペックだろうが、最近は実にリーズナブルにお求めいただけるようである。(価格についてはふせておく。)このマシンには2.2GHzのOpteron 6174が4つ搭載されている。つまり、ひとつのパッケージに12個のコアが格納されているのだ。これはすごい。いや、むしろどうしてこうなった?!というべきか。そのようなマシンを目の前にすると時代はメニイコアに向かっているんだなあと実感せざるを得ない。 今後、CPUがどんどんメニイコアに向かう流れはさけれない。コアを増やさなければCPUの性能が(システム全体としての性能が)向上しないからだ。CPUの演算回路に対して半導体素子をたくさ

    残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ!!
    hiro_y
    hiro_y 2010/08/30
    「バージョンが上がるごとに着実にスケーラビリティが向上している様子が手に取るようにわかるだろう。これからのメニイコア時代の備えも万全である。」
  • MySQLコミュニティ騒然!MySQL 5.5.4が与えるインパクト。

    先週、MySQL Conference & Expo 2010が開催され、盛況のうちに終了した。カンファレンスに合わせる形で、MySQL 5.5.3および5.5.4がリリースされたのだが、これが目を見張るような進化を遂げている。特に性能面での進化には目を見張るものがある!Jeremy ZawodnyやMark Calleghanといったコミュニティの重鎮たちも「非常にエキサイティングなリリースだ!」などと表して歓迎の意を表している。 というわけで、日はMySQL 5.5.3/5.5.4の新機能および変更点についてレビューしてみよう! おさらい。 〜 MySQL 5.5の既存の機能 〜MySQL 5.5が登場したとき、その新機能については以前にもエントリで紹介したが、ここで改めておさらいしてみよう。MySQL 5.5は、正確にいうと現在最新バージョンであるMySQL 5.1の「次の次」のバ

    MySQLコミュニティ騒然!MySQL 5.5.4が与えるインパクト。
    hiro_y
    hiro_y 2010/04/19
    MySQL 5.5.4の変更点とか。
  • Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン

    Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照(=PV)が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M

    Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
    hiro_y
    hiro_y 2010/03/23
    SPIDERストレージエンジン紹介。