タグ

2011年7月15日のブックマーク (9件)

  • MySQL :: MySQL 8.4 Reference Manual :: 9.5 Point-in-Time (Incremental) Recovery

    Point-in-time recovery refers to recovery of data changes up to a given point in time. Typically, this type of recovery is performed after restoring a full backup that brings the server to its state as of the time the backup was made. (The full backup can be made in several ways, such as those listed in Section 9.2, “Database Backup Methods”.) Point-in-time recovery then brings the server up to da

  • MySQL のJOIN に関するメモ - LukeSilvia’s diary

    内容 FROM 句のテーブルの順番と、MySQL がテーブルをJOIN する順番は別 STRAIGHT_JOIN と eq_ref, ref eq_ref になるようにするために JOIN 条件の書き方 STRAIGHT_JOIN をいつ使うか 今回の検証に用いたMySQL は4.0.26。また、例として、以下のテーブルを用いる。(テーブルは、「逆算式SQL教科書」のもの) [study]> SHOW FIELDS FROM uriage; +-------------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------+------+-----+---------+---------------

    MySQL のJOIN に関するメモ - LukeSilvia’s diary
  • Using filesort

    去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう?と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル(テンポラリテーブルではない)が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事

    Using filesort
  • KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ

    {{toc_here}} InnoDB パフォーマンスチューニング MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Ma

  • なぜMySQLのサブクエリは遅いのか。

    よくMySQLはサブクエリが弱いと言われるが、これは当だろうか?半分は当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

    なぜMySQLのサブクエリは遅いのか。
  • Radar - O’Reilly

    Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi

    Radar - O’Reilly
  • MySQL innodb_flush_method = O_DIRECTの検討 - SH2の日記

    MySQL InnoDBのパラメータでinnodb_flush_methodというものがあります。これはUNIX/Linuxにおいてデータファイル、ログファイルの読み書き方式を指定するためのもので、マニュアルの13.6.3. InnoDB Startup Options and System Variablesによると以下の3種類の設定が可能とされています。 無指定(fdatasync):デフォルトの設定です。特別なフラグなしでファイルをオープンし、書き込み時にfsync()を行います。 O_DSYNC:データファイルについてはfdatasyncと同じです。ログファイルについてO_SYNCフラグをつけてファイルをオープンします。 O_DIRECT:データファイルについてO_DIRECTフラグをつけてファイルをオープンします。ログファイルについてはfdatasyncと同じです。 今回はこのパ

  • ガラケーからスマホの怒濤の流れで割を食ったサービス|More Access! More Fun

    ※前半部分はしょりすぎで意味不明の部分があったので追記しておきます 7/18 最近、スマートフォンの浸透が著しく、携帯売り場はスマホか「らくらくホン」しか売れなくなっているという。長い爪のギャルはタッチパネルでは打てなかったがついに女性用と名打ってキーボード式のスマホまで出てきた。ガラスマですな。 某大手携帯メーカーS勤務の友人も「ガラケー市場は死にました」と言ってます。アメリカの市場では成人の35%がスマホだそうだが(ソースはこちら)、日でもこんな感じ しかしこんな急激にスマートフォンが来るとは、キャリアもコンテンツプロバイダも予測してなかったのではあるまいか。というかドコモでさえSoftBankにここまでやられたのは単にスマホの需要の見誤りだし、auなんて、もうSoftBankに抜かれて三位転落が目の前に迫っている。2011年6月でドコモ47%、au27%、SoftBank21%。5

    ガラケーからスマホの怒濤の流れで割を食ったサービス|More Access! More Fun
    twodollarz
    twodollarz 2011/07/15
    まさにイノベーションのジレンマ。既存のビジネスがあまりにもおいしすぎた。
  • MySQL