AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
レンタルサーバなら「さくらのレンタルサーバ」! 月額換算でわずか131円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能&大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
Webサイトの表示速度を早くするためにはインターネットが普及し始めた2000年頃は、Webページの表示速度は8秒以内が一般的だと言われてきたが、今や3秒以内でなければ訪問者が離れてしまうという調査結果がある。また、Googleが検索結果の順位決定に表示速度を含めることを公式発表したこともあり、今後さらに、Webページの表示速度はWebサイトの運営で重要になってくるだろう。 もし、自社サイトの表示速度がわからないのであれば、Firefoxの拡張機能には「Firebug」や「YSlow」といった、Webページの表示速度やパフォーマンスの達成度を測定できるツールがあるので、まずはこれらを活用してチェックしてみてほしい。 Webサイトの表示を高速化するための要素は、大きく分けると次の3種類がある。 この3種類それぞれの要素を改善することでページ表示は速くなるものであり、どれか1つだけを改善したとし
このセクションでは、MySQL が ORDER BY 句を満たすためにインデックスを使用できるタイミング、インデックスを使用できない場合に使用される filesort 操作、および ORDER BY に関するオプティマイザから使用可能な実行計画情報について説明します。 セクション8.2.1.19「LIMIT クエリーの最適化」 で説明されているように、LIMIT を使用する場合と使用しない場合で ORDER BY が異なる順序で行を返すことがあります。 場合によっては、MySQL でインデックスを使用して ORDER BY 句を満たし、filesort 操作の実行に伴う余分なソートを回避できます。 インデックスのすべての未使用部分と追加の ORDER BY カラムが WHERE 句の定数であるかぎり、ORDER BY がインデックスと完全に一致しない場合でもインデックスを使用できます。 ク
余分なソートを行わずに ORDER BY または GROUP BY の要求に応じるために、MySQL はインデックスを使用する場合があります。 全ての使用されていないインデックス部分と他の部分が WHERE 節内で定数であるカラムである場合、ORDER BY がインデックスに完全にマッチしない場合でもこのインデックスを使用できます。 次のクエリではインデックスを使用して ORDER BY / GROUP BY 部分を解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2 SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2 SELECT * FR
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか?半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう?と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル(テンポラリテーブルではない)が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
谷口です。 MySQLでORDER BYを付けると非常に実行時間がかかる。。。なんて経験があると思います。私もORDER BYに悩まされることが多いです。今回はORDER BYを伴うクエリのチューニングのうちの一つを紹介したいと思います。 その方法とは、サブクエリでソート済みのテーブルを作成して結合するという方法です。 たとえば、下記のようなSQL文があったとします。 SELECT t1.col1, t2.col2 FROM table1 t1, table2 t2 WHERE t1.col1=t2.col1 AND t1.col2 = 1 ORDER BY t1.col1 DESC LIMIT 10; これを下記のように、t1をサブクエリでソートしてから結合する感じです。 SELECT t1.col1, t2.col2 FROM (SELECT * FROM ta
2009/05/12 既存データベースサーバのハードディスクをSSDに置き換えた場合、どの程度パフォーマンスが向上するのか? この問いへの回答の1つとなり得るベンチマークテストを、“MrBenchmark”を名乗るサン・マイクロシステムズのチーフ・エンジニアのBenoit Chaffanjon氏が5月11日付けのブログで公開している。 ベンチマークは2種類。1つはオンメモリで処理が完了するもの、もう1つはキャッシュメモリに乗り切らずにドライブ(HDD/SSD)へのアクセスが発生するもの。テストに用いたサーバのコンフィギュレーションは以下の通り。 Solaris 10 Update 6 Oracle 10.2.0.2 Java 1.7 build 38 SLAMD 1.8.2、iGenOLTP Sun Blade X6270(Xeon X5560@2.8GHz×2、DDR3 32GB) In
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者:松信 嘉範 販売元:翔泳社 発売日:2009-09-17 おすすめ度: クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 インデックスがないと、MySQL は関連する行を見つけるために、先頭行から始めてテーブル全体を読み取る必要があります。 テーブルが大きいほど、このコストが大きくなります。 テーブルに問題のカラムのインデックスが含まれている場合、MySQL はすべてのデータを調べる必要なく、データファイルの途中のシークする位置をすばやく特定できます。 これはすべての行を順次読み取るよりはるかに高速です。 ほとんどの MySQL インデックス (PRIMARY KEY、UNIQUE、INDEX、および FULLTEXT) は B ツリーに格納されます。 例外: 空間データ型のインデックスは R ツリーを使用します。MEMORY テーブルはハッシュインデックスもサポートします。InnoDB は FULLTEXT インデックスの逆のリスト
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
携帯向けサイト「モバゲータウン」の勢いが止まらない。2010年3月の会員数は約1800万人、月間ページビュー(PV)600億という"モンスターSNS"に成長している。意外なことに、これだけのアクセスをさばくのに、memcachedをはじめとするKVS(Key-Value Store)系のインフラ・ソフトはあまり使っておらず、MySQLで十分だという。モバゲータウンのインフラ担当者に話を聞いた。 モバゲータウンを運営するDeNA(ディー・エヌ・エー)は、もともと1999年に開始したオークションサイト「ビッダーズ」で知られている。その後、オークションに加えてECサイトを開始し、auとの提携により「auショッピングモール」などで急速に成長した。 ビッダーズだけでも、数千万PV規模の大規模サービスだが、最近はモバゲータウンの成長が著しい。 「特に2009年9月から順次リリースした自社製のソーシャル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く