タグ

mysqlに関するtacchiniのブックマーク (47)

  • 大人のためのInnoDBテーブルとの正しい付き合い方。

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

    大人のためのInnoDBテーブルとの正しい付き合い方。
  • MOONGIFT: » MySQLのドキュメント作成「mysqldoc」:オープンソースを毎日紹介

    Javadoc、PHPDocなど、プログラミングソースからドキュメントを生成するソリューションは幾つか存在する。きちんとコメントを書けば、それがドキュメントになってくれるので、手間が減りつつもプログラムの品質は向上すると一石二鳥だ。 出力中 そして同様の手法をMySQLにも適用しようと言うのがこのソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはmysqldoc、MySQLの構造ドキュメント出力ソフトウェアだ。 mysqldocはターミナル上で利用するソフトウェアで、指定したデータベース(または全て)のテーブルの構造を一覧にしてくれる。カラム名、テーブルタイプ、型、デフォルト値、詳細な説明を一覧にする。 HTMLでの出力例 テーブルのステータス等も出力される。結果はテキスト(デフォルト)、HTMLまたはXMLで出力が可能だ。SSLを使った接続への対応や、トリガーやユーザファンクシ

    MOONGIFT: » MySQLのドキュメント作成「mysqldoc」:オープンソースを毎日紹介
  • Using filesort

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

    Using filesort
  • MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ

    仕事MySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'

    MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
  • 株式会社CAM

    CAMはエンタメコンテンツ、ビジネスバラエティメディア、ライフスタイルメディアを主軸に30以上のサービスを展開しています。エンタメコンテンツの分野では、国内外で圧倒的人気を誇るアーティストやアイドルグループとのパートナーシップを結び、オフィシャルファンサイトや動画関連サービスを運営しています。

    株式会社CAM
  • PDO、PEAR::DB、MySQL関数の速度比較

    サーバー側の問題もあるので、毎回安定した処理結果は得られませんでしたが、大体上表のような結果になりました。 やはりネイティブ関数は速く、mysqli関数が一番速い結果になりました。 続いて同じくネイティブ関数のmysql関数が続き、その次にPDOという結果になりました。 PDOでは、プリペアドステートメントを用いてSQLを発行したため、2回目のSQLの発行ではキャッシュが効き、劇的な速さになっています。 一番遅かったのは予想通り、PEAR::DBでした。 ネイティブ関数よりも2〜3倍遅く、PDOよりも2倍近く遅い結果となりました。 PHP用アクセラレータを導入していなければ、PEAR::DBはもっと遅くなっただろうと考えられます。 まとめ PHP5を利用していて、DBの抽象化を行いたいのであれば、PEAR系のモジュールはやめてPDOにした方が良いと言えます。 単純なSELECT文の結果でさ

    PDO、PEAR::DB、MySQL関数の速度比較
    tacchini
    tacchini 2011/01/19
    phpとデータベース接続
  • MySQL :: MySQL 4.1 リファレンスマニュアル :: 1.2.4 MySQL テーブルの最大サイズ

    Linux 2.2 では、ext2 ファイルシステム用の LFS パッチを使用することで、2 GB より大きいサイズのテーブルを使用することができます。また、Linux 2.4 には ReiserFS および ext3 が組み込まれており、これらを使用することで大きいファイルがサポートされます。現在の Linux ディストリビューションのほとんどはカーネル 2.4 に基づいており、必要な Large File Support(LFS)パッチすべてがすでに組み込まれています。しかし、それでも、有効な最大ファイルサイズはいくつかの要因によって左右されます。そのうちの 1 つが、MySQL テーブルを格納するために使用されるファイルシステムです。 Linux における LFS の詳細については、Andreas Jaeger の「Large File Support in Linux」(http:

  • joinとdelete文 | 開発日記 〜Doinet〜

    June 2016 (1) May 2016 (1) January 2016 (1) December 2015 (1) November 2015 (1) October 2015 (1) September 2015 (2) August 2015 (1) July 2015 (1) June 2015 (2) May 2015 (2) April 2015 (1) March 2015 (1) January 2015 (1) December 2014 (3) October 2014 (5) September 2014 (2) February 2014 (2) July 2013 (3) June 2013 (1) January 2013 (2) December 2012 (1) November 2012 (1) October 2012 (5) September

    joinとdelete文 | 開発日記 〜Doinet〜
  • ウェブリブログ:サービスは終了しました。

    「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

    ウェブリブログ:サービスは終了しました。
  • BLOG | 株式会社フェリックス | ferix inc.

    完全にお仕事の話です。 C 言語のプログラムコードの話。先週リリース予定だったものが週を超えてもリリースできません。弊社の(私の)エンジンの完成度不足です。デッドエンドは日・・・・だったのですが昨日 19時半に昨日中になりました(笑)。 大焦りで、緊急対応を続けましたが・・・やはり完成度は上がらず。というわけでデッドエンドを1日ずらしていただきました。それでも、1日程度では完成度が上がる見込みがありません。完全に トホー にくれておりました。 するとクライアント様より「以前は動いていたんだから差分を確認してみれば?」との神のお告げが!! 聞いた瞬間は「いやいや、そんなところに間違いは無い・・・・はず」と思いましたが、他をいろいろ眺めてみても埒があきません。四方八方手を尽くして改善策が見つからなかったのでやはりクライアントの助言に従うことにしました(というより藁にもすがってみました)。 す

  • mysql ランキング - Google 検索

    MySQL のRANK()・DENSE_RANK() 関数の使い方. MySQL の RANK()・DENSE_RANK() 関数を使うと、各行を指定した項目でランク付けをすることができます。

  • MySQL | GREE Engineering

    MySQL について GREE Engineering

    MySQL | GREE Engineering
    tacchini
    tacchini 2010/11/12
    ランキングと数が多くなった場合に人数計算しとく
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.1 数値データ型

    MySQL はすべての標準 SQL 数値データ型をサポートします。 これらの型は、概数値データ型 (FLOAT、REAL、DOUBLE PRECISION) だけでなく、真数値データ型 (INTEGER、SMALLINT、DECIMAL、NUMERIC) を含みます。 キーワード INT は INTEGER のシノニムで、キーワード DEC および FIXED は DECIMAL のシノニムです。 MySQL では、DOUBLE は DOUBLE PRECISION (非標準の拡張) のシノニムと見なされます。 また、REAL_AS_FLOAT SQL モードが有効でないかぎり、REAL は DOUBLE PRECISION (非標準のバリエーション) のシノニムと見なされます。 BIT データ型はビット値を格納し、MyISAM, MEMORY, InnoDB および NDB テーブルでサ

    tacchini
    tacchini 2010/11/11
    数値の最大値
  • 整数型 - MySQLのデータ型 - MySQLの使い方

    MySQL で利用可能なデータ型の中で整数型(TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT)の使い方について解説します。 TINYINT[(M)] [UNSIGNED] [ZEROFILL] 符号付きの範囲は -128 から 127 。符号なしの範囲は 0 から 255 。 SMALLINT[(M)] [UNSIGNED] [ZEROFILL] 符号付きの範囲は -32768 から 32767 。符号なしの範囲は 0 から 65535 。 MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] 符号付きの範囲は -8388608 から 8388607 。 符号なしの範囲は 0 から 16777215 。 INT[(M)] [UNSIGNED] [ZEROFILL] 符号付きの範囲は -2147483648 から 2147483647

    整数型 - MySQLのデータ型 - MySQLの使い方
  • yamicha.com's Blog

    今度は阪神が結構大変なことになっています。村上ファンドに取締役の変更を申し入れられているのですが、阪神側は断固反対とか。 私にとって野球などどうでも構わないのですが、村上ファンドが阪神の株を売り抜けるにしても、阪神を支配して資産を売り払うにしても、どちらにせよ極めて腹立たしい行為です。仮に村上側の提案が受け入れられれば、取締役は村上側9人、阪神側7人。村上側のうち1人はやや阪神サイドに近いとはいいますが、さてどうでしょう。 ともかく恐ろしいのは、阪神は一応電鉄会社です。こういう公共インフラがやすやすと卑怯な成金ファンドに資産目当てに支配され、資産を切り売りされるようでは大変なことですし、仮に経営にまでかかわってきたらなおさら大変です。ああいう他人のことを何とも考えぬファンドが公共機関を支配しようものなら、また福知山のようなことを起こす可能性すらあります。 最悪のシナリオは、阪神が消滅するこ

    tacchini
    tacchini 2010/11/11
    "やはりMySQLでミリ秒は使えないようです。ミリ秒を使いたければ、BIGINTかVARCHAR、DEC"
  • 俺とMySQL 〜日付型の仕様〜 - 俺と何某。

    先日MySQLを初めてさわったのだけれど、ひとつ気になった点が。 MySQLには日付を表示・計算する関数が用意されており、マイクロ秒までの精度がある。 しかし、MySQLの日付型フィールドにはミリ秒以下を格納できない仕様らしい。 うーん、謎だ。日付型フィールドでのソートとかどうするんだろ? (別の数値フィールドや文字列フィールドにミリ秒以下を持たせればいいんだろうけど) そういう設計思想なのだろうか? 理由をご存じの方がいらっしゃれば、是非ご教示願います。 参考 MySQL :: MySQL 5.6 リファレンスマニュアル MySQL :: MySQL 5.6 リファレンスマニュアル :: 11.3.1 DATE、DATETIME、および TIMESTAMPMySQL :: MySQL 5.6 リファレンスマニュアル :: 12.7 日付および時間関数

    俺とMySQL 〜日付型の仕様〜 - 俺と何某。
  • MySQL :: MySQL Forums

    Forum to discuss quality assurance techniques, such as bug reports, test cases, code patches

  • MySQLのBIGINTにミリ秒のデータを格納するとどの程度の時間まで扱えるのか計算してみた - tsimoのメモ

    BIGINTは8バイトで、正の値の最大値は9223372036854775807だ。 これをいろんな単位で表現しなおすと、 9223372036854775807[ミリ秒] 9223372036854776[秒] 153722867280913[分] 2562047788015[時間] 106751991167[日] 292471209[年] というわけで約2億9000万年。 ちなみにINT(4バイト)だと 2147483647[ミリ秒] 2147483[秒] 35791[分] 596[時間] 24[日] 4バイトの差とは斯くも偉大であったか。

    MySQLのBIGINTにミリ秒のデータを格納するとどの程度の時間まで扱えるのか計算してみた - tsimoのメモ
  • CentOS5.3にMYSQL4.1をインストール - 赤い人

    centos | 10:24 | yumでは出来ないということで初めてのソースインストール。またやるかもしれないので備忘録です。0.yumですでにmysql5とphpがインストールしていたのでサービスの終了と削除 sudo service mysqld stop sudo yum -y remove mysql sudo yum -y remove php sudo yum clean all 1.mysql実行ユーザーの作成 sudo groupadd mysql sudo useradd -g mysql -d /dev/null -s /sbin/nologin mysql 当然ですがすでに作成済みの場合は必要なし 2.ダウンロードと解凍 sudo wget -P /usr/local/src ftp://ftp.iij.ad.jp/pub/db/mysql/Downloads/My

  • CentOS5.3にmysql4.0をインストール: 30過ぎの親父のブログ

    CentOS5.3にmysql-4.0.26をインストールしました。 なぜ古いバージョン?って言われると、サーバリプレイス目的だからです。 来はRedHatES4にインストールしていたのですが、 経費削減を言われて有償が買えなくなったので、無償のOSに移行しました。 最初にmysql-4.0.26をインストールしようとしたのですが、 mysqlを # ./configure ってやると checking "LinuxThreads"... "Not found" となりエラーになります。 オプションで「--with-named-thread-libs="-lpthread"」をつけてあげたら上手く通りました。 次に # make ってやったらエラーがでたので、 google先生に質問をしたら、 http://mlog.euqset.org/archives/ml@mysql.gr.jp/