バージョン Skipfish ver 1.19b skipfish Documentation SkipfishDoc 高リスクの欠陥（システムを危険にさらす可能性をもつもの） サーバサイドSQLインジェクション（隠れた経路、数値パラメタを含む） GETやPOSTパラメタ内のあからさまなSQL-like構文 サーバサイドシェルコマンドインジェクション（隠れた経路を含む） サーバサイドXML／XPath インジェクション（隠れた経路を含む） 書式化された文字列脆弱性 整数オーバーフロー脆弱性 HTTPのPUTメソッドによるロケーション変更受け入れ 中リスクの欠陥（データを危険にさらす可能性をもつもの） HTMLドキュメントボディ内でXSS経路を保持し表現するもの（minimal JS XSS support present） HTTPリダイレクトを通してXSS経路を保持し表現するもの HTT
シリアル型 テーブルを作ったりデータを入れたり出したりするやり方はわかったんで、次はテーブルのフィールド構成をいじってみる。 リレーショナル・データベースをいじくるのに、レコードを識別させるために ID 番号を持つテーブルを作るのは一般的であろうかと。 ここでも ID 番号を持つテーブルを作っちゃう。 ID 番号はテーブル内で重複しない一意な数とか文字とかがなにかとうれしい。 ポスグレには serial 型があって、フィールド定義で serial 型で宣言すれば一意な数字を自動で割り振ってくれる。便利。Access で言うところのオートナンバー型がこれです。 第3回と第4回で作った address テーブルに ID 番号を持つ serial 型を追加してみる。 以下の内容の create2.sql ってファイルを作る。 CREATE TABLE address ( id serial,
ググっても、シェルからpsqlを呼んだ結果をファイルにリダイレクトする方法ばかりがヒットする現状はいかがなものかと思ったのでエントリをおこす。 psqlのターミナルモードで実行したクエリの結果をファイルに保存するメタコマンドは \o [{filename||command}] 以降の問い合わせの結果をfilename ファイルに保存、もしくは、以降の問い合わせの結果を別シェルに渡し、 command を実行します。引数がない場合、問い合わせの出力はstdoutにリセットされます。 "問い合わせの結果" には全てのテーブル、コマンドの応答、データベースサーバからの注意はもちろん、データベースに問い合わせを行なう(\d のような)各種バックスラッシュコマンドの出力が含まれますが、エラーメッセージは含まれません。 Oracleのsqlplusにおける spoolコマンドのようなものですが、\oコ
サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQL用topコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル
データベースのチューニングという言葉からどのようなことを想像しますか。表の設計の見直しやSQL記述を探ること、バッファプールの調整などと主にデータベース自体の調整であったりするかと思います。 しかしこうしたチューニング作業を行ったにもかかわらず、パフォーマンスがあまり変化しなかった、明確に問題が解決されなかったなどといったといった経験はないでしょうか。またより詳細な調査の結果、実はOSの設定やデバイスドライバのバージョンに原因があった、あるいはハードウェアの選択に問題点があったということも聞いたことがあるかと思います。 もちろんデータベース自体のチューニングは欠かせないものですが、なんらかの問題が起こっている場合、システム全体を考慮しなければならない状況に陥ることがあります。 一口にパフォーマンスをチューニングするといっても、ハードウェアを含めたシステム全体を考えると、考慮すべき項目は多い
最適化は、システム全体の理解が必要であるため、複雑な作業です。システムやアプリケーションに関する知識が豊富でなくても部分的なローカルの最適化は可能ですが、より高度な最適化が必要になるほど求められる知識も高度になります。 この章では、MySQL 最適化の方法説明し、その例もいくつか紹介します。ただし、常にシステムの速度をさらに上げる補足的な方法もありますが、難度も高くなることを覚えておいてください。 This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the Engli
SQL Serverというブラックボックスを開いてみる：Dr. K's SQL Serverチューニング研修（1）（1/3 ページ） SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。（編集局） ―― はじめに 「簡単に導入できるのはいいけれど、いざチューニングしようと思うとブラックボックスで手出しできない」と思われがちなSQL Server。だが、本当にSQL Serverは“いじれない”のだろうか？ 「そんなこ
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
SlowLogの設定 環境設定ファイル(Windowsではmy.ini，Linuxではmy.cnf)に次のような設定を加えるとSlowLogが有効になる。 log-slow-queries SlowLogの有効化(ログファイル名を指定可能) long-query-time=2 SlowLogに記録する処理時間の上限 log-long-format インデックスを使用しないSQL文の記録 long-query-timeパラメータは，SlowLogに記録するしきい値を秒単位で設定する。この場合には，2秒超える処理時間を費やしたSQL文を記録する。また，log-long-formatを指定すると，インデックスを使用しないSQL文もSlowLogに記録する。 SlowLogの確認 SlowLogが動作しているかどうかは，次のコマンドで確認できる。log_slow_queriesがONであれば有効と
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
レンタルサーバなら「さくらのレンタルサーバ」！ 月額換算でわずか131円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能＆大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
前回の負荷MAX、サーバ陥落寸前ですよ騒動のとき、最終的には自分で最適化する必要があるのかも知れない…と思っていたときに見つけたページです。 MySQLやPHPで同じ処理をする際にどういうふうにすればより軽いのか、という基本的な対策ばかりを集めてあります。どれもこれもあちこちで既出のものばかりですが、1カ所にまとまっているので読みやすいです。中には知らないのもあったりするかもしれません。 dublish.com - Simple Optimization for PHP and MySQL http://www.dublish.com/articles/10.html MySQLで書かれている方は割と読んだことがあるようなのが多かったですが、PHPの方は言われてみればそうかも、というようなのが多い。上記ページのコメント欄にもいろいろと有用な意見があるので、読み進めると楽しい。 そういえば以
hogeデータベースを作成します。 create table [table] ([column] [type]) - テーブル作成 データベース内に新規にテーブルを作成します。 ex. hogeテーブルを作成します。 カラムfooはint型、カラムbooはvarchar型です。 drop database [database] - データベース削除 データベースを削除します。使用には注意しましょう。 drop table [table] - テーブル削除 テーブルを削除します。気をつけて使用しましょう。 use [database] - データベース選択 使用するデータベースを選択します。 show databases - データベース表示 存在するデータベースを表示します。 show tables - テーブル表示 データベース内に存在するテーブルを表示します。 describe [ta
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
