タグ

MySQLとmysqlに関するgologo13のブックマーク (210)

  • もしもデータベースサーバがクラッシュしたら

    人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ!!人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから

    もしもデータベースサーバがクラッシュしたら
    gologo13
    gologo13 2014/09/22
    より高い可用性、整合性を保つ手段。
  • MySQLでインデックスを使って高速化するならCovering Indexが使えそう - (゚∀゚)o彡 sasata299's blog

    2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者:松信 嘉範 販売元:翔泳社 発売日:2009-09-17 おすすめ度: クチコミを見る 最近、このを読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス

    gologo13
    gologo13 2014/09/21
    Whereやソートキーだけでなく、取得するカラムも含めてインデックスを設計する。うまくインデックスを設計できると、Covering Index として扱われ、Disk I/O が発生しなくなる。
  • インデックスについて MySQLメモ

    12.インデックスについて ■インデックスの作成 ・テーブル作成時作成 mysql> create table テーブル名(作成対象カラム名 データ型 not null,index インデックス名(作成対象カラム名)); 例)mysql> create table ex_table(ex_c1 tinyint not null primary key auto_increment, -> ex_c2 varchar(15),index ex_index(ex_c1)); ・既存のテーブルに作成 mysql> create index インデックス名 on テーブル名(作成対象カラム名); 例)mysql> create index ex_index on ex_table(ex_c); 又は、 mysql> alter table テーブル名 add index インデックス名(対象カラム

  • MySQL - データベースサイズ確認!

    mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL でデータベースのサイズを確認したいことが時々あります。 MySQL では SHOW TABLE STATUS; でテーブルの各種状態を確認できますが、このコマンドではカラムを選択したり、SUM を取ったりすることができない。 以下、SQL でデータベースのサイズ確認する方法についての記録です。 0. 前提条件 OS や MySQL のバージョンは特に問わないはず。(MariaDB も同じ) 以下の記事内の SQL 文ではキーワードを英大文字で記載しているが、趣味の問題であり、英小文字でもよい。 1. 全データベースの容量確認 MySQL サーバに root でログ

    MySQL - データベースサイズ確認!
    gologo13
    gologo13 2014/09/16
    Stored procedure の使い方始めて知った
  • MySQLのロックについて - SH2の日記

    JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami

    MySQLのロックについて - SH2の日記
  • データベース千夜一夜 - PowerNews連載コラム | Developer Solutions〈開発支援ツール〉 - メシウス株式会社

    既に紹介したように、WHERE句を使っても条件を指定してレコードを絞り込めます。HAVING句との違いを知っておきましょう。 HAVING句はGROUP BY句の後ろに記述しましたが、WHERE句はGROUP BY句の前(FROM句の直後)に記述します。記述位置を間違えると正しいSQLとは見なされないので、注意しましょう。 SELECT 商品名, 金額 ,性別 FROM 累積売上_fx WHERE 性別='女' GROUP BY 商品名, 金額, 性別 実行結果は先のHAVING句を用いたものとまったく同じです。 HAVING句とWHERE句、どちらを使っても同じ結果が得られました。どこが異なるのか、両者の違いを知っておきましょう。 HAVING句はGROUP BY句と共に用いますが、WHERE句にはそういった制限はありません。それぞれの記述位置も異なっています。このことが、2つの抽出命令

    gologo13
    gologo13 2014/09/14
    今更ながら where句 と having句 の違いを理解した。
  • How to Select the First/Least/Max Row per Group in SQL

    How to Select the First/Least/Max Row per Group in SQL Published Dec 7, 2006 by Baron Schwartz in Databases at https://www.xaprb.com/blog/2006/12/07/how-to-select-the-firstleastmax-row-per-group-in-sql/ Here are some common SQL problems, all of which have related solutions: how do I find the most recent log entry for each program? How do I find the most popular item from each category? How do I fi

    How to Select the First/Least/Max Row per Group in SQL
  • 分割と整合性と戦う

    え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation

    分割と整合性と戦う
    gologo13
    gologo13 2014/09/06
    エンジニアのレベル低いのでは。
  • 漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法

    ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基中の基であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

    漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
  • mysqlのtrigger(トリガー)機能を使ってみた。 - (゚∀゚)o彡 sasata299's blog

    2009年02月03日00:02 MySQL mysqlのtrigger(トリガー)機能を使ってみた。 今日は、mysql の5.x系から使えるようになったトリガーという機能を使ってみたので、その紹介をしてみたいと思います! そもそもトリガーというのは何かというと、まぁ簡単に言うと、あるテーブルに対する特定のイベント(insert, update, delete)の前 or 後に、自動的に指定した処理を走らせる、というものです。 ∧_∧      トリガー? ぼこぼこにしてやんよ ( ・ω・)=つ≡つ (っ ≡つ=つ /   ) ババババ ( / ̄∪ 例えば、ある特定のテーブルAを更新した場合には、必ず別のテーブルBも更新しなければいけない、という場合を考えてみましょう。 トリガーを使わない場合には、プログラム側で毎回、「テーブルAを更新する処理の後に、必ずテーブルBを更新する処理

  • Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる

    最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い!」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか? 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( ->   id int unsigned not null primary key auto_increment, ->   v int unsigned not null -> ) engine=innodb

    gologo13
    gologo13 2014/08/28
    mysql 単体でこんなことできるのか。。。
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

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

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
  • MySQLノウハウ

    いろいろなからメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),

  • Creating a MySQL Docker Container

    10 Nov 2013 comments Tweet On the surface, creating a MySQL container for Docker is pretty easy, but if you want to connect in (not sure what a mysql server that didn’t allow that would be good for) and decouple your databases from your container (I’m assuming you don’t want those to go away with your container) then there are a few problems to sort out. I’m going to start with that simplistic exa

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.8 1 つのマシン上での複数の MySQL インスタンスの実行

    状況によっては、MySQL の複数インスタンスを単一マシン上で実行する場合もあります。 既存の番設定をそのままにして、新しい MySQL リリースをテストすることもできます。 または、ユーザーが自分で管理する異なる mysqld サーバーへのアクセス権を別々のユーザーに与える場合もあります。 (たとえば、ユーザーは独立した MySQL インストールを異なるカスタマ用に提供するインターネットサービスプロバイダである場合もあります。) インスタンスごとに異なる MySQL Server バイナリを使用したり、複数のインスタンスに対して同じバイナリを使用したり、この 2 つの方法を組み合わせたりすることが可能です。 たとえば、MySQL 5.7 と MySQL 8.0 からそれぞれサーバーを実行し、異なるバージョンによって所定のワークロードがどのように処理されるかを確認することもできます。 ま

  • MySQL5.0/5.1でスロークエリログを記録 - よんちゅBlog

    MySQLでスロークエリログを記録する方法は、バージョンによって設定方法が異なったり、オプション名が変更されていたりと、意外と分かりづらいことが多いのでここでまとめておこうと思います。 いずれのバージョンでも、コンフィグファイル(Linuxでは my.cnf、Windowsでは my.ini)の mysqld セクションに設定を記述することになります。 MySQL5.0の場合 MySQL5.0の設定方法は簡単で、「log-slow-queries」にログを出力するファイル名を設定するだけです。 絶対パスによる指定も可能ですが、相対パスで指定した場合はデータディレクトリからの相対パスになります。 また、スロークエリとして記録されるクエリのしきい値、つまり何秒以上のクエリをスロークエリとしてログに記録するかはデフォルトで10秒以上となっています。 この値は「long_query_time」によ

    MySQL5.0/5.1でスロークエリログを記録 - よんちゅBlog
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • オラクルはみんなが思っているほど悪者ではない | readwrite.jp

    オープンソースに明るくない人々にとっては、オラクルのMySQL運用にまつわる騒動はあまりピンと来ないかもしれない。オラクルが2010年にサン・マイクロシステムズを買収した際、オープンソースの技術者たち(私もその一人だ)は、オラクルがMySQLを台無しにするのではないかと危惧した。オラクルが開発への投資を縮小したり、技術をクローズド化するような事態を想定したのである。しかしそんなことは起こらなかった。実際にはオラクルの管理の下、MySQLのパフォーマンスは劇的に改善され、コードの大部分もオープンのまま残されている。 それでもなお、オープンソースのコミュニティには未だにオラクルのMySQL運用をバッシングする人たちがいる。ちょっとオラクルが気の毒になるほどだ。 崩壊の危機にさらされたMySQLコミュニティー確かにオラクルはコミュニティに対してあまり友好的ではなかった。そして、同社に何十億ドルも

    オラクルはみんなが思っているほど悪者ではない | readwrite.jp
  • データベース技術の羅針盤

    PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation

    データベース技術の羅針盤
  • データベース設計徹底指南

    DBエンジニアのための技術勉強会(第3回)で使用した資料です。主にリレーショナルモデルと正規化について解説しています。リレーショナルモデルの限界について正しく認識してこそ、リレーショナルモデルを理解したと言えると思います。

    データベース設計徹底指南