タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

MySQLとMysqlとmysqlに関するmytechnoteのブックマーク (356)

  • MySQL TIPS 5 ストアドプロシージャで指定した数のダミーデータを用意する2 (失敗編) - イノベートな非日常

    以前のエントリーで作ったinsert_generate_seriesを複数INSERT,複数カラムで生成データを使用可能にしてみる DROP PROCEDURE insert_generate_series; delimiter // CREATE PROCEDURE insert_generate_series( IN target VARCHAR(255) , -- insert対象のテーブル、カラム名を指定 IN value VARCHAR(255) , -- valuesを記述 @numがgenerate_seriesで生成された値になる IN start_num INT , -- 開始値 IN end_num INT , -- 終了値 IN step INT -- 増分 ) begin set @num:= start_num; set @sql:= concat('INSERT

    MySQL TIPS 5 ストアドプロシージャで指定した数のダミーデータを用意する2 (失敗編) - イノベートな非日常
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.6 マルチカラムインデックス

    MySQL は複合インデックス (つまり、複数のカラムに対するインデックス) を作成できます。 インデックスは最大 16 カラムで構成できます。 特定のデータ型では、カラムのプリフィクスにインデックスを設定できます (セクション8.3.5「カラムインデックス」を参照してください)。 MySQL では、インデックスで、すべてのカラムをテストするクエリーまたは最初のカラム、最初の 2 つのカラム、最初の 3 つのカラムというようにテストするクエリーにマルチカラムインデックスを使用できます。 インデックス定義の正しい順序でカラムを指定する場合、単一の複合インデックスにより、同じテーブルへの複数の種類のクエリーを高速化できます。 マルチカラムインデックスは、インデックス設定されたカラムの値を連結して作成された値を格納する行である、ソート済みの配列とみなすことができます。 複合インデックスの代わりに

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 24.6 パーティショニングの制約と制限

    このセクションでは、MySQL パーティショニングサポートでの現在の制約と制限について説明します。 禁止されている構造体. 次の構造体はパーティショニング式で許可されません。 パーティショニング式で許可される SQL 関数のリストについては、セクション24.6.3「関数に関連するパーティショニング制限」を参照してください。 算術および論理演算子. 算術演算子 +、-、および * の使用は、パーティショニング式で許可されます。 ただし、結果は整数値または NULL である必要があります (この章のほかの場所で説明しているように、[LINEAR] KEY パーティショニングの場合を除きます。詳細は、セクション24.2「パーティショニングタイプ」を参照してください)。 DIV 演算子もサポートされています。/演算子は使用できません。 ビット演算子 |、&、^、<<、>>、および ~ はパーティシ

  • MySQL 5.1.43リリース - SH2の日記

    出ました。今回は機能追加が1件、バグ修正が47件あります。バグ修正のうち1件はセキュリティに関するもの、それからパーティショニングに関するものが2件、レプリケーションに関するものが7件となっています。InnoDB PluginはMySQL 5.1.42に引き続きRC版の1.0.6となっています。 今回は注意すべき変更点がいくつかありますので、かいつまんで説明します。 パーティショニングに関する機能追加 パーティショニング機能に関して一つ機能追加があり、UNIX_TIMESTAMP()をパーティショニング表現として利用できるようになりました。先日のMySQL 5.5.0-m2の記事における例を書き直すと以下のようになります。 mysql> CREATE TABLE timeline ( -> id BIGINT(20) NOT NULL, -> created_at DATETIME DEF

    MySQL 5.1.43リリース - SH2の日記
  • 第1回 SQL流 条件分岐(1) ウォーミングアップ | gihyo.jp

    はじめに 私たちが通常、C言語やPerlJavaなどの手続き型言語(またそれに基礎を持つ言語)を使ってプログラミングを行う場合、最も多用する基的な制御構造が分岐とループです。この2つを使わずにプログラミングしろ、と言われたら、それはかなりきつい制約になるでしょう。腕試しや暇つぶしに試すにはおもしろいかもしれませんが、およそ実務的なコーディングは不可能になるに違いありません。 話は、SQLとデータベースの場合でも同じです。SQLにおいても、やはり分岐とループは非常に重要な役割を果たす機能であり、SQLプログラミングの際にこの2つの機能を欠かすことはできません。しかしながら、手続き型言語を使いこなすプログラマの多くが、なぜかSQLを使う段になると思い通りの制御構造を記述できないことに苛立ちを感じ、結果、非効率的なSQL文が多く生み出されています。これはなぜでしょう? SQLで分岐とループを

    第1回 SQL流 条件分岐(1) ウォーミングアップ | gihyo.jp
  • はじめての MySQL で100万件のデータを管理する時に行ったチューニングまとめ

    MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ

  • DBサーバーの負荷分散

    MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する

  • The Main Benefits of Riak

  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • TechCrunch | Startup and Technology News

    Limited space! Get on waitlist to be the first to know when tickets go live!

    TechCrunch | Startup and Technology News
  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • サーバ監視に超使える〜topコマンドのまとめ:phpspot開発日誌

    サーバ監視に超使える〜topコマンドのまとめ サーバを運用しているとよく使うtopコマンドですが、標準のtop以外にも色々便利なものがあるのでまとめてみました。 ボトルネックといえば、ネットワーク、ディスクIO、スワップ、CPU、メモリといったものが関連しますが、ツールで視覚化することでより分かりやすい対策がとれますね。 htop こちらも、通常のtopよりもさらに多数の情報を表示してくれるツール。 CPUやメモリの状態が視覚的にグラフで表示されていたり、複数CPUがある場合もそれぞれに利用率を表示してくれてわかりやすいです。 pstreeで表示するようなツリー+topコマンドのような表示も t を押せば切り替えられます。 公式サイト上にある128コア積んだマシンのhtop結果が面白い。 次のようにすべてグラフで表示されているため、128コアあったとしても瞬時に負荷が把握できますね。 io

  • 大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック

    OSC 2011 Hokkaidoの発表で使用したスライド資料です。 弊社が「ブラウザ三国志」や「英雄クエスト」といったゲームを、PHPMySQLで構築してきた上で、身につけたノウハウや、注意すべき箇所、指針などをまとめた資料となっています。

    大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
  • https://blogs.oracle.com/solaris/

  • LinuxのLVS(IPVS)でMySQLをロードバランスするときはtimeoutに注意 - (ひ)メモ

    構成 [appサーバ] -> [lvs] -> [MySQL]群 DRでMySQLのスレーブ群にロードバランス appサーバはDBコネクションのプーリング、永続化をしている 問題の現象 DBサーバ上ではmysqldへのコネクションが存在するのに、appサーバ上ではコネクションが存在しない。(netstat調べ) →無用なコネクションが残留するせいで、MySQLのmax_connectionsに達してしまう。 原因 MySQLの世界の無通信時のコネクションのタイムアウトはデフォルトで 28800秒 (8時間)。一方、IPVSの世界の無通信時のタイムアウトはESTABLISHEDなコネクションで900秒 (15分)。 # ipvsadm -Ln --timeout Timeout (tcp tcpfin udp): 900 120 300なので、DBコネクションの永続化等でコネクションを張りっ

    LinuxのLVS(IPVS)でMySQLをロードバランスするときはtimeoutに注意 - (ひ)メモ
  • memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp

    クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ

  • さくらインターネット創業日記

    Some privacy related extensions may cause issues on x.com. Please disable them and try again.

    さくらインターネット創業日記
  • 「Mobage」巨大サーバーを支えるDeNAのMySQL活用とは|【Tech総研】

    MobageなどのデータベースとしてMySQLを採用しているDeNAは、このほどMySQLコミュニティ最大のイベントで、「Corporate Contributor of the Year 2011」を受賞した。そこで示されたDeNAの世界に通用する技術力とは──。 オープンソース・データベースとして世界中で使われているMySQL。大規模なトランザクションを処理するサイト構築には不可欠の技術だが、株式会社ディー・エヌ・エー(DeNA)はMySQLを徹底して使い倒し、独自の拡張技術を開発することを通して、その可用性を高めてきた、日を代表するユーザー企業の一つとして知られている。現在、Mobage(モバゲー)サービスを動かすために、約700台のMySQLサーバーが稼働しており、その数は世界的にも有数のものだ。 4月中旬に米サンタクララで開かれたMySQLコミュニティ最大のイベント、MySQL

  • WordPressを100倍速くする! MySQLの調整やnginx proxy cache | KRAY Inc

    [追記1] 最後で説明しているproxy cacheの設定を修正しました。 [追記2] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記3] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W

    WordPressを100倍速くする! MySQLの調整やnginx proxy cache | KRAY Inc
  • DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール

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

    DeNAによる大規模なMySQLノンストップ運用の裏側にある、フェイルオーバー自動化ツール