タグ

mysqlに関するbasiのブックマーク (115)

  • mysqlで、delete文の実行計画を確認する | 会計SEの裏紙

    mysqlで、delete文の実行に30分くらいかかっているところがあったのでindexを張ったら8分くらいに短縮した。 で、ちゃんとcreateしたindexを使っているのかなあと思って、explain delete・・・と書いて実行してみたが、「#1064 - You have an error in your SQL syntax;」と言われてしまう。なのでググったら英語のページが出てきた。頑張って読んだ。 mysql explain delete? - Stack Overflow Q.削除クエリを説明する方法はありますか? A.実行計画を知りたいdelete文のfrom以降をコピーして、 select 1 from ・・・ where ・・・という文を作り、それの頭にexplainをつけて実行しろ。 ※意訳です。 要するにDELETE文を直接explainすることはできないので、

  • 真偽値の判定に、tinyint(1)を使うか、bool,boolean型を使うか、bit(1)を使うか、enumを使うか - ぽひゅっとメモ

    MySQLレベルでの話。 最近SQLの細かい挙動とか、しっかり把握しきれてないなーとか、 一度覚えたことが年が経ってあやふやになってるところが多くある。 また勉強し直したい。 RDBMSとうか、KVSだのNoSQLだのDBのシステムによって大きく違うと思うけれど、 私はMySQLとちょっとPostgreSQLとかSQLiteとか触ったくらいなしょっぱい男です(先の言い訳)。 主に扱うのはMySQLで、そのくらいしかついていけません(わかるとは言いません)。 「MySQLってそうなんだ〜。Oracleだとこうなんだよー、きゃははー」とか言われても、しょんぼりとしかしません。 題。 Rails使ってると、マイグレーションファイルでDBのテーブル定義して、 rake db:migrateでマイグレーションファイルを元にテーブルが作成されちゃう。 ここで使うDBによって、うまいこと作られる型に差

    真偽値の判定に、tinyint(1)を使うか、bool,boolean型を使うか、bit(1)を使うか、enumを使うか - ぽひゅっとメモ
    basi
    basi 2013/02/19
    tinyint(1)
  • 米国への引越とFacebook入社のご報告

    件名の通り、私は米Facebookに最近入社したことをここでご報告します。 相変わらずMySQL関係の仕事をすることになります。 チームメンバーはアジアには誰もおらず大半が米国社(Menlo Park)にいるため、自分も引っ越すこととなりました。 すでに生活の拠点を会社から10km未満というそう遠くないところに移しています。 当然ながら入社前に話をオープンにするわけにもいかないので、DeNAの中の方たちや、ごく親しい人にしかご挨拶ができずにすみませんでした。 このBlogの読者であればご存知のように、私はキャリアの途中からほぼMySQL仕事をしてきています。 実はDeNAは、世界でも指折りのMySQLのヘビーユーザとして認知されています。 去年の米MySQL Conferenceでは会社としてAwardを受けました。それも純粋に技術的な貢献が評価された上での受賞であり、「日でのコ

    basi
    basi 2012/03/27
  • MySQLのコマンドたち - すぎゃーんメモ

    http://mysql-casual.org/2011/11/mysql-casual-advent-calendar-2011.html の6日目の記事として書かせていただきます、sugyanです。 勢いで参加表明してしまい、今日慌てて久しぶりにMySQLを触りました。 MySQLでFizzBuzz ストアドプロシージャって使ったこと無かったので初めて触ってみました。 DROP PROCEDURE IF EXISTS FizzBuzz; delimiter // CREATE PROCEDURE FizzBuzz(n INT) BEGIN DECLARE i INT DEFAULT 1; WHILE i <= n DO SELECT CASE WHEN i % 3 = 0 AND i % 5 = 0 THEN 'FizzBuzz' WHEN i % 5 = 0 THEN 'Buzz'

    MySQLのコマンドたち - すぎゃーんメモ
    basi
    basi 2011/12/07
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 24.2.1 RANGE パーティショニング

    範囲によってパーティション化されるテーブルは、各パーティションに含まれる行のパーティショニング式値が指定された範囲に収まるようにパーティション化されます。 範囲は、連続しているけれども重複しないものであるべきで、VALUES LESS THAN 演算子を使用して定義されます。 次のいくつかの例では、20 のビデオ店で構成されるチェーン (1 から 20 までの番号が付けられている) の従業員レコードを保持する、次のようなテーブルを作成していると想定してください。 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31'

    basi
    basi 2011/11/28
  • パーティショニングの使用例 - http session情報

    今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする(たぶん昨日の例よりも)もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDBMySQL Cluster)ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン

    パーティショニングの使用例 - http session情報
  • Range Partitioning と日付型の選び方 - 日向夏特殊応援部隊

    だいぶ前に身を持って知った訳ですが、どう見ても BK なのでここに書いておきますよと。 型 データサイズ 日付演算 1日未満の分割 刈り込み (pruning) datetime 8 byte ○ × ○ timestamp 4 byte ○ ○ × uint(10) 4 byte × ○ ○ 1日未満の分割が必要無く、データサイズもへっちゃらと言う御仁は datetime を、日付演算なんぞ要らんという方は uint(10) がお勧め。timestamp は pruning が効かないのが泣けるです。

    Range Partitioning と日付型の選び方 - 日向夏特殊応援部隊
  • 3000req / sec と戦う - だるろぐ

    ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ

    3000req / sec と戦う - だるろぐ
  • 実録MySQLのチューニング 春の陣 - (ひ)メモ

    long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです! 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソースい潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,

    実録MySQLのチューニング 春の陣 - (ひ)メモ
    basi
    basi 2011/08/05
  • DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始

    MySQLがダウンしたときに自動的に別のMySQLへ処理を引き継ぐことで、高可用性を実現するフェイルオーバーツール「MySQL-MHA: MySQL Master High Availability manager and tools」がオープンソースとして公開されたことを、作者の松信嘉範(まつのぶよしのり)氏がブログで伝えています。 Yoshinori Matsunobu's blog: Announcing MySQL-MHA: "MySQL Master High Availability manager and tools" 松信氏はモバゲーなどで知られるDeNAに勤務しており、MySQL-MHAによる自動フェイルオーバー機能はDeNAのインフラ運用を支えているとのこと。同氏のブログから引用します。 Difficulties of master failover is one of

    DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始
  • MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック

    べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ!!などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい!! 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake(MySQL 5.5以降)やconfigure(MySQL 5.1以前)にかかる時間は除いてある。だがそれでも速い。

    MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
  • DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール

    4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範(まつのぶよしのり)氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています(英語のドキュメントも作成中とのこと)。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求

    DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール
  • 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登場!!新機能速攻レビュー
  • 「優れたMySQL DBAを見分ける27+3の質問」に対する回答例

    随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例(漢バージョン)を紹介しよう。実は質問を掲載した際「難しい!」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった!! そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある?ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー

    「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
    basi
    basi 2011/04/11
  • ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン

    ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
  • INSERT ON DUPLICATE KEY UPDATE and REPLACE INTO

    Jonathan Haddad writes about REPLACE INTO and INSERT ON DUPLICATE KEY UPDATE. Really, Why MySQL has both of these, especially both are non ANSI SQL extensions ? The story here seems to be the following – REPLACE INTO existed forever, at least since MySQL 3.22 and was a way to do replace faster and what is also important atomically, remember at that time MySQL only had ISAM tables with table locks

    basi
    basi 2011/01/24
  • MYSQLの日付関数で、 NOW(),SYSDATE(),CURRENT_DATE()の違いを教えて下さい。…

    MYSQLの日付関数で、 NOW(),SYSDATE(),CURRENT_DATE()の違いを教えて下さい。 perlを使用した場合、取得する情報に違いがあると聞いたことがありますが、 詳細を忘れてしまいました。 ご存知の方、ご教授よろしくお願い致します。

  • mixi の年末年始対策 2009-2010 - mixi engineer blog

    こんにちは。パートナーサービス部の加藤和良です。 2008年末に、mixi の年末年始対策について紹介しました。今回は、ここ数年の年末年始対策の歩みと、今年の対策について紹介したいと思います。実をいうと、設計も実装も自分じゃなかったりするのですが、このまま歴史に埋もれていくのも悲しいので、関係各所に取材してみました。 2008年末をふりかえる まずは、2008年末をふりかえってみましょう。 あのころはまだ mixi の機能も少なく、年末年始の負荷は主に日記に集中していました。そこで当時は ID Generator の改善 - mod_perl をあいだにはさんで MySQL への接続数を減らす 最新情報DBへの書き込みを非同期に - Q4M をつかって負荷を時間軸で分散する という2つを日記に実装したのでした。 しかし、2008年末から2009年のお正月にかけて、mixi はまたも日記に

    mixi の年末年始対策 2009-2010 - mixi engineer blog
  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • bk-mysql

    このドキュメントは最近メンテされていない項目が数多くあります。 リンクが切れていたり、現状のmysqlでは直っていたり、変更されている可能性が多々。 その点だけ注意して下さい。 InnoDBへ移行する際に把握しておかなくてはいけない事affected_rowsは英語で「影響を受けた行数」という意味疑似csv形式で出力するソースからの構築時のトラブルなんかよく分からないけどmysqlが重い時mysql_use_result()とmysql_store_result()の違いSHOW TABLE STATUS;my.cnfDBのエンコーディングとVARCHAR(n)の関係リファレンスレプリケーション一行だけmysqldumpするテーブルが破損した時にmysqlをとめずにバックアップを取る場合のパターンなんかよく分からないけどエラーが出た時テーブルの構造を、CREATE TABLEフォーマットで

    basi
    basi 2010/09/28