タグ

mysqlに関するmhagのブックマーク (139)

  • mysqlでいちいちshow databasesとか打つのがめんどい→readlineのマクロで解決 - (ひ)メモ

    MySQLでいちいちshow tables;とか打つのがだるい。\tみたいなalias設定できないのかなぁ http://twitter.com/weboo/status/1658300902 おぉ、readlineのマクロを使えばいいのかー http://twitter.com/weboo/status/1658314333 なるほ!ってことでちょっと設定してみました。 # ~/.inputrc $if mysql "\C-xd": "show databases;" "\C-xt": "show tables;" "\C-xu": "select user,host,password from mysql.user order by user,host;" "\C-xb": "select user,host,db from mysql.db order by user,host;"

    mysqlでいちいちshow databasesとか打つのがめんどい→readlineのマクロで解決 - (ひ)メモ
    mhag
    mhag 2009/06/01
  • 限界までMySQLを使い尽くす!!

    どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値(16MBなど)に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは

    限界までMySQLを使い尽くす!!
    mhag
    mhag 2009/05/20
  • SDC SQUARE April 2009

    昨年12月8日、MySQL5.1がリリースされました。一般提供開始後わずか10日で25万ダウンロードを記録し、デベロッパーの関心がひときわ高い製品です。今回、MySQLのパフォーマンスチューニングのポイントを、サン・マイクロシステムズ株式会社の島拓也さんと奥野幹也さんにうかがいました。(取材:SDC編集局) 編集局:現在のお仕事について教えてください。 奥野さん:私はMySQLの有償版のサポート業務に携わっています。お客様からいただくいろいろな問い合わせ、たとえば、MySQLの使い方や仕様・動作の細かい質問にお答えしています。トラブルシューティングやパフォーマンスチューニングなども含まれます。 島さん:私はx86サーバの販売を担当しています。x86サーバの差別化要因としてMySQLなどの上位のアプリケーションを含めたソリューションのご提案が主な仕事の内容となります。 編集局:サポートチーム

  • やってはいけない!!MySQLに悲鳴をあげさせる10の方法

    いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ?固まったか?」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。

    やってはいけない!!MySQLに悲鳴をあげさせる10の方法
    mhag
    mhag 2009/04/07
  • Using filesort

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

    Using filesort
    mhag
    mhag 2009/03/18
  • オトコのソートテクニック2008

    今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx

    オトコのソートテクニック2008
    mhag
    mhag 2009/03/18
  • MySQLによるデータウェアハウス構築

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のWangです。 データウェアハウス(以下DWH)という言葉になじみのない方は検索していただいたほうがよいかもしれません。 検索するのがめんどい、という方は、かみ砕いた表現ができなくて恐縮ですが、 基幹系システムから抽出したデータを目的をもって再構成し、 使用可能な状態に保管されたデータの集合体、とお考えください。 オークションでは、具体的には出品、入札、落札などのトランザクションデータや、 それをいろいろな単位で集計したデータなどが該当します。 ここでいう単位というのはたとえば、日ごと、週ごと、月ごとや、以前の記事でも紹介されている カテゴリといったものになります。 こういったデータは、運用、運営、

    MySQLによるデータウェアハウス構築
    mhag
    mhag 2009/02/11
  • Amazon Elastic Block Store(EBS)でmysqlを動かしてみたよ - shibataismの日記

    Good job, Amazonということで、実際にやってみました。 詳しくは http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663&categoryID=100 を参照していただければと思いますが、日語の方が良いという方はこちらをご参考までに。 $で始まるコマンドはクライアントのterminalから。 #で始まるコマンドはECサーバーで実行。 とりあえず、テスト目的なので、ゼロからEC2インスタンスを作るところからやっています。 インスタンス起動とポート確認 とりあえず、僕自身は一番centosが慣れているのですが、Amazonオフィシャルのイメージにcentosが無いので、rightscaleが提供しているイメージを使うことに。 詳しくは http://vividtone.seesaa.ne

    Amazon Elastic Block Store(EBS)でmysqlを動かしてみたよ - shibataismの日記
    mhag
    mhag 2008/08/23
  • https://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/mysql_direct_access.php

  • https://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/mysql_show_status.php

    mhag
    mhag 2008/06/10
  • x86_64環境でRubyからMySQLのクエリを実行するときの問題が示す根本的な問題… - グニャラくんのグニャグニャ備忘録@はてな

    ニコニコ大百科というサービスをリリースしたわけですが、 開発言語を選定する際に 「最近書いてなくて忘れかけてるし、部下も書けるし、 たまにはRubyで書いてみようじゃないか。」 とテキトーに決めたことをちょっと後悔。 特にRubyのbase64に関しては マニュアルの使用方法の項目にはencode64などの関数を直に使う方法が書いてあるが、生で使うと怒られる(encode64 is deprecated; use Base64.encode64 instead)。 Base64.encode64()を使うと、今度は途中とお尻に勝手に改行が入る。マニュアルには書いていない挙動(るびまには書いてあるが)。Base64.encode64().split.joinなどをして改行を除去する必要がある。 さらに、urlsafeなエンコードをしようとすると、Base64.encode64().split

    x86_64環境でRubyからMySQLのクエリを実行するときの問題が示す根本的な問題… - グニャラくんのグニャグニャ備忘録@はてな
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.7 SHOW ステートメント

    SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント

    mhag
    mhag 2008/05/07
  • 【レポート】Facebookのデータセンターに見るMySQL活用事例 - MySQLカンファレンス (1) 熱気に満ちた4日間 - MySQL Conference and Expo | エンタープライズ | マイコミジャーナル

    4月14日から17日までの4日間、米カリフォルニア州サンタクララにおいて、MySQL Conference and Expo(以下、MySQLカンファレンス)が開催された。MySQL関連の最大のイベントである。セッションは有料で、日円で10万円を超える金額にもかかわらず、参加登録者数は2,000人近くに達し※、日からも多くのユーザーが参加していた。 ※ セッション参加のできない、展示会場のみの申し込み者も含む。 今回のMySQLカンファレンスでは、複数データセンターにまたがってMySQLを活用するような大規模事例、ペタバイト級の規模に挑戦する事例、MySQL Clusterの事例、Heartbeat + DRBDによる高可用性の事例など、さまざまな事例が発表された。とくにFacebookは、1万台のWebサーバ、800台のキャッシュサーバ(memcached)、そして1,800台のMy

    mhag
    mhag 2008/05/01
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.4 異なるソースおよびレプリカのストレージエンジンでのレプリケーションの使用

    レプリケーションプロセスでは、ソース上の元のテーブルとレプリカ上のレプリケートされたテーブルが異なるストレージエンジンタイプを使用するかどうかは関係ありません。 実際、default_storage_engine システム変数はレプリケートされません。 これは、異なるレプリケーションシナリオに異なるエンジンタイプを利用できるという点で、レプリケーションプロセスにいくつかの利点を提供します。 たとえば、典型的なスケールアウトシナリオ (セクション17.4.5「スケールアウトのためにレプリケーションを使用する」 を参照) では、トランザクション機能を利用するためにソースで InnoDB テーブルを使用しますが、データの読取りのみであるためトランザクションサポートが不要なレプリカでは MyISAM を使用します。 データロギング環境でレプリケーションを使用する場合は、レプリカで Archive

  • MySQL レプリケーションの設定 - とみぞーノート

    1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確

  • MySQL Conference 2008に行って来た - stanaka's blog

    今年もMySQL Conference 2008に行ってきました。社内向けの報告資料と雑多なメモですが、よろしければ参考にしてください。 *1 概要 MySQLがSunに買収されて始めてのConference 8セッション並列で、OSCONの規模にだいぶ近い MySQLが扱うトラフィック量・データ量がどんどん大きくなってきており、それにどう追従するか、という観点の話が多い 買収の話とか "MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に"というのは、かなりミスリーディングな記事 実体は一部のセキュリティ形の機能やnative storage engine-specific driverをMySQL Enterpriseとして出す、という話 Backup機能や、Falcon, Mariaといったストレージエンジンの開発では、Community ServerとE

    MySQL Conference 2008に行って来た - stanaka's blog
    mhag
    mhag 2008/04/22
  • http://www.technobahn.com/news/2008/200804172000.html

    mhag
    mhag 2008/04/18
  • MySQL/PostgreSQL+Sennaで行うラクラク全文検索……Tritonn&Ludia導入のポイント | gihyo.jp

    Tritonn、Ludia、そしてSennaとは…… 昨今のWeb 2.0と呼ばれるようなWebシステムでは、一般的に大量のコンテンツデータを内部に保有しているのではないでしょうか。大量のコンテンツから目的のコンテンツをユーザが選び取る手段の一つとして全文検索が挙げられます。全文検索とは、検索対象コンテンツの中身すべてに対して検索を行うことを指します。たとえば、タグやタイトルを対象にした検索だけでは、目的のコンテンツを発見できないような場合に有効な検索です。 データベースに保持された大量のデータを簡単に全文検索したい、という場合も多いことでしょう。稿では、それを実現にする全文検索システムとして、次の2つを取り上げて紹介します。 Tritonn Ludia これらはそれぞれ、Tritonnは「MySQL⁠」⁠、Ludiaは「PostgreSQL」という、Webシステムを開発する上で人気の高

    MySQL/PostgreSQL+Sennaで行うラクラク全文検索……Tritonn&Ludia導入のポイント | gihyo.jp
  • mysqlコマンドで、テーブル名とかカラム名の補完(completion)をする方法 - (ひ)メモ

    追記: rehash(auto-rehashも含む)すると、SQL文の補完(seleでタブ打鍵とか)が効かなくなるよと、はす向かいの人に教えてもらいました。 個人的には、SQLは「mysql> help select」とかでオンラインヘルプがびょっと出るので、スキーマの補完ができるんならSQLの補完はとりあえずあきらめてもいいかなと思っています。 常々、テーブル名とか補完できるといいなーと思っていたので、ボロっときいてみたら教えてもらいました。あざーーーーっす! id:mikihoshi++ id:tokuhirom++ id:precuredaisuki++ おかげで効率が300%上がりました。(Benchmark::Stopwatchで計測) http://dev.mysql.com/doc/refman/5.1/en/mysql-command-options.html#option

    mysqlコマンドで、テーブル名とかカラム名の補完(completion)をする方法 - (ひ)メモ
    mhag
    mhag 2008/01/23
  • 【レビュー】登場! MySQL5.0.54 - 大幅向上のパフォーマンスを検証する (1) InnoDBのCPUスケーラビリティが大幅に改善 | エンタープライズ | マイコミジャーナル

    1月2日、MySQL5.0の最新版であるMySQL5.0.54がMySQL ABよりリリースされた。5.0.54は、5.0系列のマイナーバージョンアップという位置づけであるが、「高負荷時にInnoDBが長時間待たされる問題の修正」と「InnoDBCPUスケーラビリティの向上」という非常に重要な修正が行われている。稿ではパフォーマンスの改善点を中心に、新バージョンの主な変更点を紹介する。 5.0.54は、5.0系列のマイナーバージョンアップという位置づけであるが、「高負荷時にInnoDBが長時間待たされる問題の修正」と「InnoDBCPUスケーラビリティの向上」という非常に重要な修正が行われている(Bug 29560)。CPUスケーラビリティについては、MySQL ABとしての公式なベンチマーク結果はまだ明らかにされていないが、コミュニティベースでの検証では、少なくとも8CPUコアまで

    mhag
    mhag 2008/01/18