AMDもしくはIntelの64ビットシステムで32ビットバイナリを使用しています

チップアーキテクチャとインストールされているOSは共にそのシステム上で稼働するソフトウェアの性能に影響を与えます。64ビットのシステムで32ビットのソフトウェアを動作させることは可能ですが、一般的に32ビット環境で動作するようにビルドされたものよりも64ビットで動作するようにビルドされたソフトウェアの方が性能が高くなります。

デフォルトの頻度6:00:00

デフォルト自動クローズ有効？no

ホストの範囲指定が広すぎるアカウントがあります

MySQLサーバに、ホストの範囲指定が広すぎるユーザアカウントがあります。 MySQLアカウントはユーザ名とホスト名の両方により識別されます。 これはmysql.userテーブルのUserおよびHost列から検索されます。 User値はクライアントがサーバに接続するときに入力必須の名前です。 Host値はユーザがそこから接続を許可されたホスト（1つまたは複数）を示します。 この値がリテラルなホスト名である場合、そのアカウントはそのホストからのみ接続できます。 ホスト名に「%」ワイルドカード文字が含まれている場合は、そのユーザはそのワイルドカードと一致するすべてのホストから接続でき、場合によっては、全ホストのうちどこからでも接続できます。

セキュリティの見地からは、リテラルなホスト名が最善であり、 % は最悪です。Host値にワイルドカードを含むアカウントは、リテラルなホスト名を使用しているアカウントに比べ、攻撃が行いやすくなります。 攻撃する場合は、広範囲のマシンから接続を試みるからです。

たとえば、あるアカウントが rootおよび % ユーザで % を含むホスト値を含む場合、パスワードさえわかっていれば、 あらゆるマシンからrootユーザとして接続できることになります。 一方、ホスト名がlocalhostまたは127.0.0.1の場合、アタッカーはそのサーバホストからrootユーザとして接続することしかできません。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ no

アカウントにグローバル権限があります

MySQLサーバにすべてのデータベースとテーブル（*.*）への権限を持つユーザアカウントがある場合があります。 ほとんどの場合このようなグローバル権限はMySQLのrootユーザにしか許可されるべきではありません。 これは通常信頼できるユーザに対するバックアップを目的とするものです。 これは通常信頼できるユーザに対するバックアップを目的とするものです。 DROP、ALTER、DELETE、UPDATE、INSERT および LOCK TABLESのようなグローバル権限は、他のユーザに悪影響を与える可能性があるため危険です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

アカウントがセキュリティの低い古いパスワードハッシュを使っています

MySQL4.1以前は、パスワードハッシュはPASSWORD()関数による16バイトのものでした。MySQL4.1およびそれ以降では、この関数は41バイト以上のハッシュ値を生成するように変更され、セキュリティが強化されました。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？no

強力なMySQL権限を持つアカウントがあります

特定のアカウントの権限が危険な可能性があります。 このような権限は必要時に信頼するユーザに対してのみ許可されるべきです。 たとえば、FILE権限はユーザがデータベースサーバ上のファイル（取り扱いに注意が必要なOSシステムファイルを含む）への読み書きを許可します。 PROCESS権限は、実行中の文の監視を許可します。 また、SHUTDOWN権限は、サーバのシャットダウンを許可します。 さらに、GRANT権限は他の人への権限の付与を許可します。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？no

エージェントホストの Dashboard に対する同期のタイムアウトが発生しました

データの統一性の維持と日々のシステム管理処理の容易化には、サーバ間のログ、ファイル、タイムスタンプの比較を伴いますが、サーバが全てのシステムにクロックを発信し、データセンターがお互い UTC 時間に対して同期がとれていることが重要です。1 つのサーバのクロックが、数分もしくは数時間他の 1 つのサーバから遅れていると、それらの 2 つのサーバのデータベースもしくはファイルシステムで生成されたタイムスタンプには、同程度の差異が生じます。そのため、タイムスタンプに依存してデータアイテムの新鮮さをテストする場合、または問題を診断したり、システム間でタイムスタンプを比較する場合、この時間差のよって、作業が複雑になってしまいます。

さらに、Serveice Manager のホストマシンとエージェントを実行するマシン間の時間差によって、MySQL Enterprise Monitor Dashboard に表示されるデータとグラフに歪が生じてしまいます。たとえば、1 つのエージェントマシンの時間が Service Manager マシンに対して 1 時間遅れている場合、そのエージェントが監視しているサーバはダウンしているように認識されBug #45937を参照)、エージェントが開始してから最初の 1 時間、そのサーバのグラフにはデータは表示されません。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ yes

サーバへの接続失敗の割合が高すぎます

MySQLへの接続の試行が打ち切られたということは、サーバまたはネットワークに問題があることが考えられます。 あるいは、このMySQLサーバへのDoS攻撃やパスワードクラッキング攻撃が行われていることを示す可能性があります。 接続打ち切り数は以下の場合に増加します。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ no

AUTO_INCREMENT フィールドのほぼリミットに達しました

多くのアプリケーションが固有識別の目的で、固有の数値やシーケンスを生成する必要があります(例えば、カスタマ ID 、バグまたはトラブルチケットタグ、メンバーシップまたは注文番号など)。MySQLにおいてこれを行うメカニズムは AUTO_INCREMENT 列属性と呼ばれ、自動的に連続番号を生成します。

しかし、生成できる番号の範囲はデータタイプによって制限されます。たとえば、TINYINT UNSIGNED 列における可能な最大の値は 255 です。データタイプの最大値を超える値を生成しようとすると(例えば AUTO_INCREMENT 列に NULL 値を追加しようとする)、データベースエラーが発生し、アプリケーションが正常に動作しません。

MySQL の AUTO_INCREMENT の主要な目的は、 positive整数の連続値を生成することです。AUTO_INCREMENT 列において、非正数の値の生成はサポートされていませんので、それらの列を SIGNED から UNSIGNED に設定することで、範囲を倍にすることがでる場合があります。

デフォルトの頻度06:00:00

デフォルト自動クローズ有効？ no

バイナリログファイル数が上限を超えています

バイナリログはDML、DDLおよびセキュリティ変更のログをキャプチャし、バイナリフォーマットで格納します。 バイナリログはレプリケーションを可能にするだけでなく障害復旧時のデータのロストを防ぎます。 また、これによりデータベースに対する全ての変更を追跡することが可能になります。 しかしながら、バイナリログはディスクスペースとファイルシステムリソースを消費するため、このマスターサーバへのスレーブからの接続が必要なくなった後、また、バックアップが終了した後は実働環境のサーバから削除することができます。

デフォルトの頻度デフォルトの頻度

デフォルト自動クローズ有効？ no

バイナリログスペースが上限を超えています

バイナリログはDML、DDLおよびセキュリティ変更のログをキャプチャし、バイナリフォーマットで格納します。 バイナリログはレプリケーションを可能にするだけでなく障害復旧時のデータのロストを防ぎます。 また、これによりデータベースに対する全ての変更を追跡することが可能になります。 しかしながら、バイナリログはディスクスペースを消費するので、このマスターサーバへのスレーブからの接続が必要なくなった後、また、バックアップが終了した後は実働環境のサーバから削除することができます。

デフォルトの頻度

デフォルト自動クローズ有効？ no

バイナリログの使用がディスクキャッシュメモリの上限を超えています

バイナリログの使用がバイナリログキャッシュメモリの上限を超えると、過剰なディスク操作が実行されるようになります。パーフォーマンスを最適化するためには、バイナリログへ記録されるトランザクションがバイナリログキャッシュ内に収まるようにする必要があります。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ no

バイナリログが制限されています

バイナリログはDML、DDLおよびセキュリティ変更のログをキャプチャし、バイナリフォーマットで格納します。 バイナリログは、障害復旧時のデータのロストを防ぎます。 また、これによりデータベースに対する全ての変更を追跡することが可能になります。

--binlog-do-dbおよび--binlog-ignore-dbオプションにより特定のデータベースに限定することができます。 しかしながら、これらのオプションを使用すると、復旧時のオプションとシステム変更を確認できる機能も制限されます。 しかしながら、これらのオプションを使用すると、復旧時のオプションとシステム変更を確認できる機能も制限されます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

バイナリログが有効になっていません

バイナリログはDML、DDLおよびセキュリティ変更のログをキャプチャし、バイナリフォーマットで格納します。 バイナリログは、障害復旧時のデータのロストを防ぎます。 また、これによりデータベースに対する全ての変更を追跡することが可能になります。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

バイナリログの書き込みがディスクと完全に同期していません

デフォルトではバイナリログは毎回の書き込みごとにディスクと同期するわけではありません。もし、サーバホストやオペレーティングシステム、もしくはMySQLサーバがクラッシュしてしまうと、最後のステートメントがディスクに書き込まれない可能性があります。sync_binlog グローバル変数により、何回目のエントリごとにバイナリログをディスクと同期せるかを設定することが出来ます。この値を1に設定すると最も安全ですが、データベースの性能は最も低下します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

バイナリログの自動削除が早すぎです

バイナリログはDML、DDLおよびセキュリティ変更のログをキャプチャし、バイナリフォーマットで格納します。 バイナリログは、障害復旧時のデータのロスを防ぎます。これはマスタレプリケーションで、スレーブサーバへ送られるステートメントの記録として使用されます。 また、これによりデータベースに対する全ての変更を追跡することが可能になります。

しかし、それらが使用するログファイルの数とスペースは、特に処理の集中したサーバで急速に増加する可能性があります。そのため、適切なバックアップを保管している上で、不要になったそれらのファイルを定期的に削除することが重要です。expire_logs_daysパラメータは、バイナリログの自動削除を有効にします。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

Cluster データノードのメモリが少なくなっています

データノードに構成されたメモリ量が少なくなったときのアドバイスです。全てのメモリが消費されると、データベースの挿入処理が失敗し始めます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Cluster データノードインデックスメモリが少なくなっています

データノードに構成されたインデックスメモリ量が少なくなったときのアドバイスです。全てのメモリが消費されると、データベースの挿入処理が失敗し始めます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Cluster データノード Redo バッファスペースが少なくなっています

Redo バッファが埋まり始めたときのアドバイスです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？no

Cluster データノード Redo ログスペースが少なくなっています

Redo ログスペースが埋まり始めたときのアドバイスです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Cluster データノード Undo バッファスペースが少なくなっています

Undo バッファが埋まり始めたときのアドバイスです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Cluster データノード Undo ログスペースが少なくなっています

Undo ログスペースが埋まり始めたときのアドバイスです

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Clusterデータノードが実行していません

実行していないデータノード数を示します。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

接続数が多すぎます

MySQLサーバの接続数が上限に達すると、それ以上のユーザ接続が確立できなくなり、クライアント側のアプリケーションにエラーが表示されます。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

CPU I/O使用率が高すぎます

CPU の I/O 数は適切に設定されたシステムでは低く抑えられるべきです。 ディスクやネットワークのパーフォーマンスに問題があるため、CPU I/O使用量が多すぎるという結果を招いていることが考えられます。

CPU I/O使用率が高すぎます 00:01:00

デフォルト自動クローズ有効？ no

CPUの使用率が高すぎます

適切に設定されたシステムでは、CPUの使用は、低から中の間に抑えるようにします。 CPUが過剰に使用される場合、RAMの不足、ディスクのフラグメンテーション、クエリのチューニング不足など、問題があることが考えられます。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

CREATE TABLE LIKE がソーステーブルのいかなる権限も必要としない

バグ#25578が原因で、データベースへのなんのアクセス権限を持たないユーザが、そのデータベース内のテーブル構造をまだコピーできます。データベース内のテーブル構造を知ることにより、やる気になったハッカーに知見を与えるかもしれませんし、他のセキュリティ上の弱点とあわせてハッキングを進めることを許してしまいます。

このバグは後のバージョンのMySQLサーバで修正済みです

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

SQLステートメントが実行されるたびに、データがディスクへフラッシュされています

MySQLは、SQLステートメントを実行するたびにディスク上のデータファイルをwrite()システムコールを用いて更新し、オペレーティングシステムにディスクへの同期処理を担当させます。 --flushオプションを使用して各SQLステートメントの後に強制的にディスクへすべてのデータをフラッシュするようにMySQLを設定することができますが、パーフォーマンスに悪く影響します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

名前の大文字小文字を区別するためデータベースの互換性が低いと考えられます

OSが大文字小文字を区別する設定である場合、データベースおよびテーブル名も同様になります。MySQLを1つのプラットフォームで使用している場合は、このことを気にする必要はありません。しかしながら、サーバ設定によっては、複数のプラットフォーム間でテーブル変換を行いたい場合、ファイルシステムの大文字小文字認識の違いにより問題が発生することがあります。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

日付のハンドリングバグによりサーバがクラッシュする可能性がある

日付のハンドリング操作に関係する２つのバグが、サービス障害(DoS)攻撃により、サーバをクラッシュさせる可能性がある:

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

max_prepared_stmt_countにデフォルト値が使用されています

プリペアドステートメントは1回以上実行するよく似たステートメントの性能を向上させることが出来ます。その最たる理由は構文解析が一度で済むからです。さらに、プリペアドステートメントを使えばステートメントの代わりにデータのみを送信するだけで済むようになるため、ネットワークのトラフィックを減らすことも可能です。

しかしながら、プリペアドステートメントはクローズするまでMySQL Server内部のメモリを消費します。従って、プリペアドステートメントは適切に、一度に使用できる数を制限して使用することが大切です。 max_prepared_stmt_count のデフォルト値はお使いのアプリケーションもしくは環境にとって適切でない可能性があります。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

InnoDBのネクストキーロッキングを無効にするとサーバがクラッシュすることがあります

いくつかのバグの影響で、InnoDBのネクストキーロッキングを無効にするとサーバがクラッシュすることがあります。

これらのバグは後のバージョンのMySQLサーバで修正済みです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

イベントスケジューラが無効になりました

イベントスケジューラは、非常に役に立つ機能です。これは、SQL コマンドを特定の時点で、あるいは定期的に決まった間隔で実行するためのフレームワークです。 概念的に、Unix の crontab("cron job" とも呼ばれる) あるいは、Windows のタスクスケジューラと似ています。

基本的なアーキテクチャは非常にシンプルです。イベントは、開始した日と時刻および反復発生タグを付けて格納されたルーチンです。一旦定義されてアクティブ化されると、リクエストされたときに実行します。トリガとは異なり、イベントは特定のテーブルの操作ではなく、日時にリンクされます。イベントスケジューラを使用することで、データベース管理者は、最小限の労力で繰り返し発生するイベントを実施することができます。よくある用途としては、古くなったデータの整理、統計のためのサマリテーブルの作成、サーバのパフォーマンスと使用状況の監視があります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

ディスク上のテンポラリテーブルの過剰な使用が検出されました

テンポラリテーブルの構築に、 tmp_table_sizeまたはmax_heap_table_sizeを超えたスペースが必要とされる場合、MySQLはサーバのtmpdirディレクトリにディスクベースのテーブルを作成します。また、TEXTまたはBLOBカラムを含むテーブルは自動的にディスク上に置かれます。

性能の観点からすると、巨大なテンポラリテーブルがディスク上に作成される場合を除き、テンポラリテーブルは概ねメモリ上に作成されるべきです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

ロックされているプロセスが多すぎます

環境、ストレージエンジン、その他の要因によって、1 つのプロセスが、他のプロセスが必要とするリソース(テーブルや行)などにアクセスし、そのリソースが解放されるまで、2 番目のプロセスが先へ進めないという状況になることがあります。この場合、その2番目のプロセスはリソースが解放されるまで、"locked" ステートになります。多くのプロセスがロックされた状態になると、重大な競合に関する問題か、長く実行しているセッションのロック解放に関する問題の可能性があります。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

長期間実行しているプロセスが多すぎます

通常、アプリケーションとデータベースは、クエリを迅速に実行するように設計されています。多くのクエリの実行時間が長すぎる場合(例えば数秒以上)、異常が発生している可能性があります。そのような場合、クエリを調整するか書き直す、あるいはインデックスを追加して、パフォーマンスを改善する必要があります。データベーススキーマを再設計する必要がある場合もあります。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

ロックされている長時間実行プロセスが多すぎます

通常、アプリケーションとデータベースは、クエリを迅速に実行し、さらに、共有リソースを他のクエリが解放するのを待機するようなリソースの競合を回避するように設計されています。多くのクエリがロックされ実行時間が長すぎる場合(例えば数秒以上)、パフォーマンストラブルか、リソース競合が発生している可能性があります。そのような場合、クエリを調整するか書き直す、あるいはインデックスを追加して、パフォーマンスを改善する必要があります。データベーススキーマを再設計する必要がある場合もあります。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

サーバへの接続に失敗しました

MySQLへの接続試行打ち切りが多すぎるということは、サーバまたはネットワークに問題があることが考えられます。 あるいは、このMySQLサーバへのDoS攻撃やパスワードクラッキング攻撃が行われていることを示す可能性があります。 接続打ち切り数は以下の場合に増加します。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

connect_timeout変数を超過したとき。

flush_timeをゼロ以外の値に設定すると、すべてのテーブルはflush_time秒ごとにcloseされ、それに伴いリソースが解放され、フラッシュされていないデータがディスクへ同期されます。使用中のシステムの信頼性が低く異常停止や再起動が頻繁に発生する場合、この方法で強制的にテーブル変更を反映させるとパーフォーマンスは低下しますがテーブルの破損やデータのロストの可能性は低くなります。このオプションは、Windowsオペレーティングシステム、あるいはシステムリソースが非常に限定された環境のみで使用することを推奨します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

一般クエリログが有効になっています

一般クエリログには、mysqldが行うことが全般的に記録されます。クライアントが接続または接続解除したときに、サーバはこのログに情報を書き込みます。また、クライアントから受け取ったSQLステートメントを毎回ログに記録します。一般クエリログは、クライアントの動作に問題があると想定された場合などに、クライアントがmysqldへ送信したステートメントを正確に知りたいという用途で使うと非常に便利です。

しかしながら、一般クエリログは本番環境では有効にするべきではありません。理由は次の通りです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

key_cache_block_size に対して不適切な値が設定されるとMyISAMテーブルを破壊することがあります

MySQL Serverはkey_cache_block_sizeオプションから何バイトかを差し引いて、次に小さい512バイトの境界になるまで値を小さくします。その結果、ブロックサイズは2の累乗ではなくなります。key_cache_block_sizeシステム変数を2の累乗でない数に設定すると、MyISAMテーブルが壊れてしまいます。

このバグは新しいバージョンのMySQL serverにおいて修正されています。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

メモリ上のテンポラリテーブルはHEAPテーブルの最大サイズによって制限されます

テンポラリテーブルに必要なスペースが、 tmp_table_sizeもしくはmax_heap_table_sizeのいずれかの値を超えると、MySQL Serverはテンポラリディレクトリにおいてディスク上にテーブルを作成します。性能の観点からすると、巨大なテンポラリテーブルがディスク上に作成される場合を除き、テンポラリテーブルは概ねメモリ上に作成されるべきです。性能の観点からすると、巨大なテンポラリテーブルがディスク上に作成される場合を除き、テンポラリテーブルは概ねメモリ上に作成されるべきです。多くのデータベース管理者は、 tmp_table_sizeを適切に設定していますが、同じ効果を持つ max_heap_table_sizeの設定をしばしば忘れます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

Windows上のInnoDBのフラッシュ方法が不正です

Windowsで innodb_file_per_tableWindowsで innodb_flush_methodが unbuffered に設定されている場合、MySQLを起動できず、OSエラーコード87が返されることがあります。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

インデックスが効率的に使用されていません

対象のサーバはインデックスを効果的に使用していないようです。Handler_read_rnd_nextおよびHandler_read_rndの両方の値（これらはフルテーブルスキャンにより読み込まれた行数と回数が反映されます）が、Handler_read_keyや Handler_read_nextなどのインデックスアクセスを示すHandler変数と比較して高くなっています。インデックスが適切に使用されるよう、テーブルおよびクエリを見直してください。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

InnoDBバッファキャッシュのヒット率が最適化されていません

論理I/Oは物理I/Oの数倍高速です。 DBAは物理I/Oをなるべく低く抑えるべきです。 論理I/Oは物理I/Oの数倍高速です。 DBAは物理I/Oをなるべく低く抑えるべきです。 論理I/Oに余裕がない場合、DBAはすべてのI/Oを最低に抑える必要がありますが、ベストなのは、データアクセスをできるだけメモリで実行することです。 InnoDBを使用する場合、ほとんどのデータアクセスはRAMで発生します。 従ってInnoDBバッファキャッシュのヒット率は高くなるべきです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

InnoDBバッファプールへの書き込みがパーフォーマンスのボトルネックになっている可能性があります

パーフォーマンスを最適に保つためには、InnoDBバッファプールへのページ書き込みに待機が発生するようなことがあってはなりません。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

InnoDBの二重書き込みバッファが有効になっています

InnoDBは、斬新なフラッシュテクニックである二重書き込みを使用しています。これにより、システムクラッシュや電源異常時のリカバリの安全性が増し、ほとんどのUNIX系のオペレーティングシステムでfsync()操作回数を減らしパーフォーマンスを向上することができます。

これにより、システムクラッシュや電源異常時のリカバリの安全性が増し、ほとんどのUNIX系のオペレーティングシステムでfsync()操作回数を減らしパーフォーマンスを向上することができます。二重書き込みバッファへのデータ書き込みとフラッシュが完了した後にのみ、そのページはデータファイルの本来の位置に書き込まれます。ページ書き込みの途中でオペレーティングシステムがクラッシュした場合でも、リカバリ時に二重書き込みバッファから正しいコピーを見つけることができます。

デフォルトの頻度06:00:00

デフォルト自動クローズ有効？ no

InnoDB 高速シャットダウンが有効です

データベースのファイルのセットで一度 InnoDB Plugin を使用した場合、そのデータベースを InnoDB Plugin がインストールしていない MySQL でインストールした場合に発生する可能性のあるクラッシュを避けるように注意する必要があります。InnoDB Plugin が有効であるときに MySQL サーバを停止する際、スローシャットダウン (SET GLOBAL innodb_fast_shutdown=0) を使用することを強くお薦めします。 これによって、以前のバージョンの InnoDB を使用していても、プラグインによって書き込まれたログファイルおよびその他のシステム情報が問題を起こすことはありません。

スローシャットダウン (innodb_fast_shutdown=0) を推奨する理由は、InnoDB Plugin がトランザクション UNDO ログに特別なレコードを書き込み、それを MySQL の組み込み InnoDB が読み取るときに問題を起こすからです。特に、これらの特別なレコードは、COMPRESSED または DYNAMIC テーブル内のレコードが更新されたか削除され、そのレコードがオフページに保存されたカラムを含む場合に書き込みこまれます。組み込み InnoDB はこれらの UNDO ログを読み取ることはできません。さらに、組み込み InnoDB は、読み取ることのできないテーブル(COMPRESSED または DYNAMICフォーマット）に影響のある不完全なトランザクションのロールバックを行うことができません。

通常のシャットダウンが必ずしも UNDO ログ を空にしないことにも注意してください。通常のシャットダウンは、 innodb_fast_shutdown=1 である場合（デフォルト）に行われます。 InnoDB がシャットダウンしているとき、修正のコミットが不完全なアクティブトランザクションがあるか、それらが読み取りビューを拘束し、そのため UNDO ログからのバージョン情報の消去を防ぐ可能性があります。通常のシャットダウン(innodb_fast_shutdown=1)の後に InnoDB が再起動するとき、すべての未完了のトランザクションはロールバックし、古いバージョン情報を消去されます。そのため、ダウングレードのプロセスにおいて、スローシャットダウン(innodb_fast_shutdown=0)を行うことが重要です。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

InnoDB ファイルフォーマットチェックが無効または不正です

InnoDB Plugin が ib-file セットを開く際ににクラッシュまたはデータの破損を防ぐため、ib-file セット内で使用されているフォーマットをサポートしているかをチェックします。システムがクラッシュまたは「ファーストシャットダウン」(innodb_fast_shutdown を 0 より大きく設定)に後に再起動した際、現在のソフトには、新しすぎるフォーマットであるオンディスクストラクチャ(REDO または UNDO エントリまたはダブルライトページ) がある可能性があります。リカバリプロセスにおいてこれらストラクチャへのアクセスがあると、データファイルに十代な損傷を及ぼす恐れがあります。すべてのリカバリプロセスの開始前にファイルフォーマットのスタートアップチェックを行い、それによってInnoDB Plugin ドキュメントの"Possible Problems"セクションで説明されている問題を防ぎます。

innodb_file_format_check を OFF、または使用中のフォーマット以外に設定することは、リカバリプロセスの実行を許可し、前のシャットダウンがクラッシュしたか「ファーストシャットダウン」である場合、データベースを破損する恐れがあり大変危険です。前回の シャットダウンが確実に innodb_fast_shutdown=0 で行われたときのみ、innodb_file_format_check を無効にし、基本的にリカバリプロセスが発生しないようにします。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

InnoDBのフラッシュ方法が最適ではないようです

nnodb_flush_methodを変更した方がInnoDBのパーフォーマンスを引き出せる可能性があります。GNU/LinuxおよびUNIXのいくつかのバージョンでは、fsync()を呼び出すか（InnoDBはデフォルトで使用します）あるいは別の似た方法でファイルをディスクにフラッシュしますが、この方法は非常に遅い場合があります。データベース書き込みに満足のいくパーフォーマンスが出ない場合、innodb_flush_methodパラメータの設定としてO_DIRECTかまたはO_DSYNCを試してみることができます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

InnoDB INFORMATION_SCHEMA Plugins が見つかりません

INFORMATION_SCHEMA テーブル -- INNODB_CMP、INNODB_CMPMEM、INNODB_TRX、NNODB_LOCKS、および INNODB_LOCK_WAITS -- は、圧縮 InnoDB テーブル、圧縮 InnoDB バッファプール、現在 InnoDB 内で実行している全てのトランザクション、トランザクションが拘束しているロック、およびリソース(テーブルまたは行)へのアクセスを待機しているトランザクションをブロックしているロックのライブ情報を含んでいます。これらのテーブルは、InnoDB Plugin エンジンのアクティティとパフォーマンスを監視する上で非常に有益です。

しかし、これらの INFORMATION_SCHEMA テーブルは、それ自体が MySQL サーバのプラグインです。それらを InnoDB Plugin ユーザガイドの説明通りにインストールしなければなりません。それらがインストールされない場合、それらを使用してInnoDB ストレージエンジンを監視することはできません。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

InnoDBログバッファがトランザクション後毎回ディスクにフラッシュされています

デフォルトでは、InnoDBのログバッファはログファイルにトランザクションのコミットごとに書き出され、ディスクへのフラッシュ操作がログファイルに対して実行されます。この仕組みによりACIDに準拠しています。クラッシュ時、1秒程度のトランザクションをロストすることが許容できるなら、innodb_flush_log_at_trx_commit0または2に設定することでパーフォーマンスを向上できます。この値を2に設定した場合、オペレーティングシステムがクラッシュするか電源異常が発生したときのみ、最後の1秒分のトランザクションが消去される場合があります。これはスレーブサーバでは有用です。1秒程度のデータロストは、必要に応じてマスターサーバから復元することができるからです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

InnoDBログにおける待ちの発生がパーフォーマンスのボトルネックになっている可能性があります

パーフォーマンスを最適に保つためには、InnoDBログバッファに対するDML操作時に待機時間が発生するようなことがあってはなりません。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

InnoDB が最新のファイルフォーマットを使用していません

InnoDB Plugin は、便利な 2 つの機能を持っています -- compressed tablesおよび long variable-length columns stored off-page。適切な環境において、両機能ともシステムのパフォーマンスを改善することができます。しかし、これらの新しい機能を有効にするには、InnoDB が新しいファイルフォーマットを使用するように設定する必要があります。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

InnoDB Strict Mode が OFFです

SQL 内のタイポやシンタックスエラー、またはさまざまなオペレーションモードや SQL コマンド の組み合わせによる意図しない結果に対処するため、InnoDB Plugin には "Strict Mode" が用意されています。このモードでは、InnoDB は警告を発行して指定コマンドを処理するのではなく、エラーを発生します。これは MySQL の sql_mode と類似し、MySQL が受け付ける SQL シンタックスをコントロールし、エラーをサイレントに無視するか、入力シンタックスとデータ値を有効するかどうかを決定します。

Strict Mode で実行していない場合、新しい句や設定をCREATE TABLE および ALTER TABLE の ROW_FORMAT および KEY_BLOCK_SIZE に使用するのは複雑です。Strict Mode で実行しない場合、InnoDB が無視するシンタックスエラーがあり、テーブルかインデックスを生成し、メッセージログに警告のみ残します。InnoDB Strict Mode がオンの場合、そのようなエラーは即エラーを発行し、テーブルおよびインデックスは作成されず、結果としてコマンドが実行された時点でエラーを補足するため時間が節約されます。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

InnoDBテーブルスペースを自動的に拡張できません

入力データに応じてInnoDBテーブルスペースを自動的に拡張することができない場合、アプリケーションが空き容量以上のデータを生成すると容量不足エラーが発生し、アプリケーションに問題が発生します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

InnoDB トランザクションログのサイズ設定が不適切です

チェックポイント操作の頻発を防ぎ、全体的な物理I/Oを減らすために（これは大量書き込みを行うシステムをスピードダウンさせかねません）、バッファプールのサイズにより異なりますが 、InnoDB トランザクションログのサイズを、概ねバッファプールの50-100%に設定します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

セキュリティの低いパスワード認証オプションが有効になっています

MySQL4.1以前は、パスワードハッシュはPASSWORD()関数による16バイトのものでした。MySQL4.1およびそれ以降では、この関数は41バイト以上のハッシュ値を生成するように変更され、セキュリティが強化されました。 しかしながら、4.1以前のバージョンのシステムから移行されたユーザテーブルの下位互換性を確保するために、古い、セキュリティの低いPASSWORD()関数を使用したパスワードハッシュを持つアカウントのログインを受け付けるように設定できます。 しかし、この設定は推奨されません。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

セキュリティの低いパスワード生成オプションが有効になっています

MySQL4.1以前は、パスワードハッシュはPASSWORD()関数による16バイトのものでした。MySQL4.1およびそれ以降では、この関数は41バイト以上のハッシュ値を生成するように変更され、セキュリティが強化されました。 古いバージョンのクライアントプログラムへの下位互換性を確保するため、短いパスワードハッシュ（バージョン4.1以前用）を生成するように設定できます。 しかしながらこれは推奨されません。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

INSERT ON DUPLICATE KEY UPDATE不具合によりレプリケーションが壊れることがあります

INSERT … ON DUPLICATE KEY UPDATE文でAUTO_INCREMENT値がインサートに対して自動生成され、いくつかの行が更新された場合、AUTO_INCREMENTカラムの範囲の消失が早すぎるために、更新された行1つにつき1つの自動生成値がロストします。 影響されるMySQLのバージョンは、5.0.24から5.0.34および5.1.12から5.1.17です（それぞれを含む）。

元になる問題がレプリケーションに影響を与える可能性があるため（マスターとスレーブで値が異なる）マスタースレーブともに現在のバージョンにアップグレードすることを推奨します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

キーバッファサイズが4GBを超えています

ディスクI/Oを最小にするために、MyISAMストレージエンジンはキーキャッシュ（またはキーバッファ）を使用して、もっとも頻繁にアクセスされるテーブルブロックをメモリ内に保持します。 しかしながら、MySQL 5.0.52 より前のバージョンでは、たとえ 64 ビットシステムであってもキーバッファサイズは4GB以下に限られます。 それ以上大きな値を設定すると、mysqldが実際のバッファを4GB以上に増加させようしたときにクラッシュする可能性があります。Windows の32ビットと64ビットシステムのおいては、MySQL のバージョンが5.0.52 以上であったとしても、key_buffer_size は4GB に制限されます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

キーバッファサイズがキーキャッシュに対して最適化されていない可能性があります

キーキャッシュヒット率は、ディスクからではなくメモリ内のキーキャッシュからキーが読み込まれる割合を表します。 最適な割合は通常99％以上です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

キーバッファサイズがシステムRAMに対して最適化されていない可能性があります

対象のサーバには、キーキャッシュに振り向ける十分なメモリがないようです。 専用サーバでは、一般に、このキャッシュにはRAM全体の25％から50％を使用します。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

LOAD DATA文のローカルオプションが有効です

LOAD DATA文はサーバホスト上のファイルをロードすることができます。 また、LOCALキーワードが指定されると、クライントホストのファイルをロードすることもできます。

LOAD DATA文のLOCALオプションをサポートした場合、次の2つの潜在的なセキュリティ問題があります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

Lock 競合が多すぎます

総ロック数に対し、ロックを確保するために待機しているテーブル操作の割合が高いとパーフォーマンスが低下する可能性があります。これが起こるのは行レベルでロックするストレージエンジンではなく、MyISAMなどのようにテーブルレベルのロックをサポートするストレージエンジンを使用している場合です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

接続プロトコル内の不正な形式のパスワードパケットがサーバをクラッシュさせる

バグ#28984が原因で、接続プロトコル内の不正な形式のパスワードパケットがサーバをクラッシュさせます。これはサービス障害(DoS)攻撃を起こし得ます。

このバグは後のバージョンのMySQLで修正済みです

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

接続上限に達したか、もうすぐ達しそうです。

MySQLサーバの接続数が上限に達すると、それ以上のユーザ接続が確立できなくなり、クライアント側のアプリケーションにエラーが表示されます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

GRANTオプションにセキュリティ改善が欠けている

GRANTステートメントはMySQLユーザアカウントの作成とアカウントへの権限付与に使われている。バグ15756と14385のために、ある環境下では権限が誤って付加されるかもしれません。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

マルチバイトエンコーディングでSQLインジェクションを起こし得ます

バグ8378が原因で、C API関数のmysql_real_escape_string()でエスケープしたときに、サーバーが文字列を不正にパースします。その結果キャラクタセットを意識してmysql_real_escape_string() 関数を使っても、SQLインジェクションが起こりえます。

このバグは後のバージョンのMySQLサーバで修正済みです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

MyISAMテーブルの修復に複数のスレッドが使用されました

スレッドを複数同時に使用すると、MyISAMの修復における性能を向上させることが出来ます。しかしながら、その際にいくつかのバグによりテーブルとインデックスの破壊が引き起こされる可能性があります。 (#11527, #11684, #18874). マニュアルにも記載がありますが、これらのバグが修復された後でもこの機能はベータ品質です。マニュアルにも記載がありますが、これらのバグが修復された後でもこの機能はベータ品質です。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

MyISAMの同時挿入が適切に設定されていない可能性があります

MyISAMはテーブルレベルのロックを使用しているため、INSERTとSELECTステートメントが同時に大量に実行されると、INSERTが完了するまでの間SELECTがすべてブロックされるためパーフォーマンスが悪くなる可能性があります。MyISAMの同時挿入が適切に設定されていない可能性があります

デフォルトの頻度

デフォルト自動クローズ有効？ no

MyISAM インデックスの統計情報がありません

MySQL オプティマイザは、SQL クエリの実行にインデックスを使用するかどうかを選択するため、インデックスの統計情報が必要です。計情報がない、または古い統計情報は、すぐれた、十分な情報に基づいたアクセスプランを選択をする、オプティマイザの性能を制限します。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

MyISAMキーキャッシュのヒット率が最適化されていません

キーキャッシュヒット率は、ディスクからではなくメモリ内のキーキャッシュからインデックス値が読み込まれる割合を表します。 最適な割合は通常99％以上です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

MySQLエージェントがメモリを過度に使用しています

MySQL エージェントが基本的な監視に必要とするメモリの量はかなり小さく一定で、有効にしているルールの数に依存します。しかし、Query Analyzer が有効な場合、エージェントを通してどのクエリを監視し解析するにしても、エージェントはかなりのメモリを使用する可能性があります。このような場合、使用されるメモリは固有の正規化クエリの数、クエリ例、EXPLAIN例に依存します。さらに、サービスマネージャにクエリを送信する必要のあるネットワークの帯域にも依存します。一般的に、Query Analyzerで使用されるメモリ量は小さく、 良く抑制されていていますが、環境によって、特にLinux の古いバージョンでは過度になることがあります。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ no

MySQLエージェントはデータベースサービスに接続していません

サーバを監視し、ベストプラクティスのためのアドバイスを表示するためには、MySQL Enterprise Service Agent がMySQL データベースサービスに接続できなければなりません。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

MySQLエージェントに接続できません

MySQLサーバを監視するには、モニターおよびアドバイザサービスエージェントが実行中でサービスマネージャと通信できなければなりません。 エージェントがサービスマネージャと通信できないと、サービスマネージャは監視先のMySQLデータベースサーバか起動中かどうか認識できません。 現在の統計情報が収集できず、そのサーバに対してスケジュール設定されたルールを適用することができません。

デフォルトの頻度 00:00:01

デフォルト自動クローズ有効？ yes

MySQL サーバが再起動しました

実用的な作業を実施するには、データベースサーバは継続的に稼働する必要があります。実稼働環境のサーバが、数週間、数か月、さらにそれより長期間稼働することが正常です。あるサーバが再起動した場合、それは計画的なメインテナンスによるものである可能性や、予期しないイベントによるもので、調査が必要である可能性もあります。

デフォルトの頻度 00:05:00

1デフォルト自動クローズ有効？ no

MySQLサーバに接続できません

作業を実行するには、ローカルMySQLデータベースサーバに接続できなければなりません。 MySQLネットワークサービスエージェントがサーバに通信できない場合、そのサーバが起動していないことが考えられます。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

InnoDBに対してネクストキーロッキングが無効にされていますが、バイナリログが有効になっています

InnoDBにおいてネクストキーロッキングを無効にすることで、特定の状況下で性能を向上させることが可能です。しかしながら、それによりレプリケーションやバイナリログからのリカバリ時にデータ不整合を引き起こす可能性があります。MySQL 5.0.2から、このオプションはバージョン4.1.xの時よりも安全でないものになりました。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

プリペアドステートメントの総数に制限がない

バグ#16365が原因で、接続毎にオープンできるプリペアドステートメントの総数に制限がありません。これはサービス障害(DoS)攻撃を起こし得ます。そしてステートメントの総数が非常に多くなったとき、サーバはメモリ不足(OOM)エラーでクラッシュするでしょう。

このバグは後のバージョンのMySQLで修正済みです

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

myisam-recoverの値が設定されていません

>myisam-recoverオプションを使用すると、MyISAMテーブルが何らかの理由で不正になったときに、MyISAM自動クラッシュリカバリが有効になります。 このオプションが設定されていないと、テーブルに不正が発見されたときテーブルが壊れていると見なされ、SELECTを実行したり、DML操作を実行することができなくなります。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

許可されていないユーザが全てのデータベースにおいて、データベース、テーブル、またはインデックスに対して権限を持っています

SELECT、INSERT、ALTERなどの権限はデータを閲覧したり変更したりするだけでなく、システムの性能へも影響を与えます。これらの操作はユーザが本当にアクセスを必要とするデータベースのみに限定されるべきです。それにより、他のユーザが使用しているアプリケーションやデータへうっかりと影響を与えてしまうことを防ぐことができます。

デフォルトの頻度 01:00:00

デフォルト自動クローズ有効？ no

許可されていないユーザが全てのデータベースに対してGRANT権限を持っています

GRANT権限はいくつかの特定のデータベースに限定されるべきですが、全てのデータベースに対して付与された場合、そのユーザが全てのデータベース上で持っている権限を他のユーザに対して与えることを可能にしてしまいます。これは、データベース、テーブル、ストアドルーチンに使用できます。そのような権限は出来るだけ少ないユーザに限定されるべきです。本当にGRANT権限が必要なユーザは、そのユーザが責任を持つデータベースに限定して権限を持つべきであり、全てのデータベースに対してGRANT権限を持つべきではありません。

デフォルトの頻度 01:00:00

デフォルト自動クローズ有効？ no

許可されていないユーザがサーバー管理者権限を持っています

SHUTDOWNやSUPERのような特定の権限は、主にサーバの管理に使用されます。これらの権限のうちいくつかは、サーバをシャットダウンしたり動作中のプロセスを強制終了させたりすることが出来るため、システムに対して甚大な影響を持ち得ます。このような操作は少数のユーザに限定されるべきです。

デフォルトの頻度 01:00:00

デフォルト自動クローズ有効？ no

オブジェクト変更： データベースが変更されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： データベースが作成されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： データベースがドロップされました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： 関数が作成されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： 関数が削除されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベース構造や関数にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： インデックスが作成されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： インデックスがドロップされました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： テーブルが変更されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベース構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： テーブルが作成されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベース構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： テーブルが削除されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベース構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクト変更： ユーザが削除されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベース構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

オブジェクトの変更が検出されました

開発環境では、データベースおよびオブジェクトへの変更は正常な操作と考えられますが、本番環境ではそうではありません。本番環境においては、データベースの構造にいかなる変更が生じた場合でも、常に変更理由を把握しておくべきです。

デフォルトの頻度 00:10:00

デフォルト自動クローズ有効？ no

プリペアドステートメントが有効利用されていません

プリペアドステートメントは1回以上実行するよく似たステートメントの性能を向上させることが出来ます。その最たる理由は構文解析が一度で済むからです。さらに、プリペアドステートメントを使えばステートメントの代わりにデータのみを送信するだけで済むようになるため、ネットワークのトラフィックを減らすことも可能です。

しかしながら、プリペアドステートメントは準備するために時間がかかりますし、クローズするまでメモリを消費するため、適切に使用することが大切です。もし使用後にプリペアドステートメントをクローズしなければ、他の用途に使用できるメモリを不必要に拘束してしまうことになります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

プリペアドステートメントが有効利用されていません

プリペアドステートメントは1回以上実行するよく似たステートメントの性能を向上させることが出来ます。その最たる理由は構文解析が一度で済むからです。さらに、プリペアドステートメントを使えばステートメントの代わりにデータのみを送信するだけで済むようになるため、ネットワークのトラフィックを減らすことも可能です。

しかしながら、プリペアドステートメントは準備するために時間がかかりますし、クローズするまでメモリを消費するため、適切に使用することが大切です。もし、ステートメントを数回しか実行しないような場合は、プリペアドステートメント作成のオーバーヘッドは価値が見合わないものになるでしょう。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

クエリキャッシュのヒット率が最適化されていません

クエリキャッシュが有効な場合、通常キャッシュは頻繁に「ヒット」します。 これはキャッシュ内のクエリは別のユーザ接続によっても再利用されるからです。 ヒット率が低い場合、キャッシュに割り当てられたメモリが十分でないか、そのサーバでは同一のクエリが繰り返し発行されていないか、INSERT、UPDATE または DELETE 文が頻繁に発行されすぎてクエリキャッシュ内の文が無効になっていることが考えられます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

クエリキャッシュが利用できませ

MySQLはSELECT文のパースと実行を繰り返して行わなくてもよいように、結果をメモリにキャッシュすることができます。 使用中のアプリケーションが同じクエリを何度も繰り返して実行している場合、結果をキャッシュすることでパーフォーマンスが著しく向上します。クエリキャッシュをサポートするMySQLのバージョンまたはバイナリを使用することが重要です。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

クエリキャッシュが有効になっていません

クエリキャッシュを有効にすると、頻繁に実行されて大きな結果セットを返すクエリでは、最大200%のパーフォーマンス向上が期待できます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

クエリキャッシュのサイズが小さすぎる可能性があります

クエリキャッシュが一杯になったとき、クエリをキャッシュに追加することが必要になると、キャッシュを空けるために最近使用されていないクエリが削除されて新しいクエリが挿入されます。 このようなことが頻繁に起きるような場合、キャッシュサイズを増やしてスワッピングの頻発を防ぎます。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ no

RAMの使用が多すぎます

システムを安定稼働させるには適度なメモリが必要とされます。 使用可能なメモリがないと新しいプロセスやスレッドは開始できません。 またOSも過剰なページングを実行します。 （ブロックをメモリとディスク間でスワップさせるため）。

デフォルトの頻度 00:01:00

RAMの使用が多すぎます no

ルートアカウントがリモートログイン可能です

デフォルトでは、MySQLは通常MySQLサーバの管理に使用されるルートアカウントに無制限の権限を持たせています。 MySQL実行中のマシンにログインできるユーザのみにアクセスを制限するため、このような強力な権限をもつユーザによるリモートログインを、できるだけ許可しないようにすべきです。 これは、権限を持たないユーザがアクセスしてシステムを変更することを防ぐために役に立ちます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

ルートアカウントにパスワードがありません

ルートユーザアカウントには権限の制限がありません。 これは管理作業を実行することを想定しているからです。 権限を持たないユーザがアクセスしてシステムを変更することを防ぐために、権限を持つアカウントには強力なパスワードを付けるべきです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ yes

5 文字より長い UTF8 CHAR 列の行ベースレプリケーションが壊れています

バグ #37426のため、85 文字より長いCHAR() UTF8 フィールドが使用されていると、行ベースレプリケーションが壊れます。

このバグは、その後のバージョンの MySQL Server で修正されています。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

セキュリティ関連の変更：ユーザーへ権限が与えられました

開発環境では、データベースセキュリティ権限の変更は正常な操作と考えられますが、実働環境では、データベース権限についてのセキュリティ変更がいつ行われたかを知り、また、その変更が許可された必須のものかを確認しておくことが賢明です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

セキュリティ関連の変更：ユーザーから権限が破棄されました

開発環境では、データベースセキュリティ権限の変更は正常な操作と考えられますが、実働環境では、データベース権限についてのセキュリティ変更がいつ行われたかを知り、また、その変更が許可された必須のものかを確認しておくことが賢明です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

セキュリティ関連の変更が検出されました

開発環境では、データベースセキュリティ権限の変更は正常な操作と考えられますが、実働環境では、データベース権限についてのセキュリティ変更がいつ行われたかを知り、また、その変更が許可された必須のものかを確認しておくことが賢明です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

BINLOG ステートメントにセキュリティリスクがあります

バグ#31611のため、 任意のユーザが BINLOG ステートメントを実行することができますが、これは、事実上、ユーザアカウントに関連付けられた権限(GRANT ステートメントで与えられた)に関わらず、任意の SQL ステートメントを実行できることになります。これによって、任意の接続ユーザは任意の希望する権限を取得し、任意の希望のデータを編集し、テーブルの追加削除を行うことなどができます。

このバグは後のMySQL サーバのバージョンで修正されています。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

サーバにデフォルトの「test」データベースが含まれます

デフォルトで、MySQLにはtestという名前のデータベースが含まれ、誰でもアクセスできます。 このデータベースはテスト用のもので、実働環境への移行前に削除されるべきです。 デフォルトの testデータベースは誰でもアクセスでき、権限設定が厳しくないので、インストールプロセスの一部として即座にドロップされるべきです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

サーバにパスワードのないアカウントがあります

パスワードのないアカウントは特に危険です。 アタッカーはユーザ名を推量するだけでよいからです。 すべてのアカウントにパスワードを付けることは、権限を持たないユーザがアクセスすることを防ぐために役に立ちます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ yes

サーバに匿名アカウントがあります

匿名MySQLアカウントを使うと、クライアントはユーザ名を指定せずにサーバに接続することができます。 MySQLの匿名アカウントはよく知られているので、削除すると権限を持たないユーザがシステムにアクセスすることを防ぐために役に立ちます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ yes

サーバにルートユーザアカウントが含まれます

デフォルトでは、MySQLは通常MySQLサーバの管理に使用されるルートアカウントに無制限の権限を持たせています。 このアカウントの名前を「root」にしておく必要はありません。 このような強力な権限を持つアカウントは、見つけやすい名前であるべきではありません。 MySQLのルートアカウントはよく知られているので、名前を変更すると権限を持たないユーザがシステムにアクセスして変更するのを防ぐために役に立ちます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

サーバによる強制的なデータの完全性チェックが無効になっています

SQLモードはどのようなSQLシンタックスがMySQLによりサポートされるか、およびどのようなデータの適合性チェックがなされるべきかを定義するものです。有効なSQLモードがない場合、サーバによる強制的なデータ完全性チェックが行われる手段がありません。これは入力されるデータが不正であってもサーバに拒否されず、入力されるデータが対象となるカラムのデータタイプにあわせたデフォルト値に変更されることを示します。しかしながら、MySQL4.1からクライアントが自分のセッションのSQLモードをいつでも変更できるようになったことに注意してください。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

サーバによるデータ完全性チェックが厳密ではありません

SQLモードはどのようなSQLシンタックスがMySQLによりサポートされるか、およびどのようなデータの適合性チェックがなされるべきかを定義するものです。MySQL Serverが様々な種類のシンタックスとデータ適合性チェックの組み合わせて使用できるようなオプションがあります。しかしながら、最も高いレベルのデータの完全性を保証するために、TRADITIONAL、 STRICT_TRANS_TABLES、 または TRICT_ALL_TABLESのうち少なくとも一つを使用する必要があります。

しかしながら、MySQL4.1からクライアントが自分のセッションのSQLモードをいつでも変更できるようになったことに注意してください。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブのネットワーク機能停止検出待機時間が長すぎます

スレーブは、マスターから最新データを取得する機能に影響を与え、その結果レプリケーションを遅延させる原因となるネットワーク接続機能停止に対応できる必要があります。 しかしながら、このスレーブは、ネットワーク機能停止後、slave_net_timeout 秒を経過しないとデータを受信できていないことを認識できません。slave_net_timeoutを減らして、機能停止の検出と解決がより迅速に行われるようにすることができます。 このパラメータのデフォルトは3600秒（1時間）です。 多くの環境でこの値は大きすぎます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブエラー: 不明または不正なタイムゾーン

タイムゾーン名とステートメント、関数、データタイプを組み合わせて使用するために、サーバを設定し、それらの情報をOSのライムゾーンファイルを MySQL データベースのテーブルのセットにロードし、理解できるようにする必要があります。しかし、MySQL のインストレーション手続きでそれらのタイムゾーンテーブルは作成しますが、ロードはしません。それらは、インストレーションのあとで、手動でロードしなければなりません。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレーブの実行位置が読み込み位置よりも大幅に遅れています

スレーブがマスターから更新を受け取るとき、I/Oスレッドはリレーログとして知られるローカルファイルにデータを格納します。 スレーブのSQLスレッドはリレーログを読み込み、そこに含まれる更新を実行します。I/Oスレッドが現在書き込んでいるものより、SQLスレッドが読み込もうとしている位置が遅れている場合、それはレプリケーションが遅延しかけていて、スレーブに指示されたクエリの結果に最新の変更が反映されていない可能性があることを示しています。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレーブが停止しました

スレーブでレプリケーションが停止してしまうと、スレーブはマスターから最新の文を取得できず、それらをスレーブ上で実行することもできません。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

スレーブにレプリケーションエラーが発生しました

スレーブがマスターから更新を受け取ったとき、スレーブ上のデータがサーバ上のものと一致するためには、その更新がローカルで適用される必要があります。 スレーブ上で更新の適用中にエラーが発生すると、スレーブのデータはサーバと一致しなくなる場合があり、これはレプリケーションが壊れた可能性があることを示します。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレーブに不適切な権限を持つログインアカウントがあります

スレーブ上でテーブルの変更およびドロップを実行するとレプリケーションが壊れる場合があります。 スレーブが非レプリケーションテーブルのホストになっている場合を除き、このような権限のアカウントは必要ありません。代わりに、 read_onlyフラグをONにセットし、SUPER 権限を持つユーザからのアップデート、またはスレーブスレッドから実行されたアップデート以外は、サーバが許可しないようにすることを検討してください。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブのマスターとの通信に問題があります

スレーブはマスターに接続して最新のデータを取得する必要があります。 接続できない場合、あるいは定期的に接続に問題が発生する場合、レプリケーションが遅延します（つまり、スレーブはマスターに書き込まれた最新データを持たない場合が発生します）。

デフォルトの頻度00:05:00

デフォルト自動クローズ有効？ no

スレーブのレプリケーションが停止しました

スレーブのI/OとSQLの両方が実行されないと、スレーブはマスターから最新の文を取得できず、またそれらの文をスレーブ上で実行することもできません。 つまりレプリケーションはまったく停止しています。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

スレーブのI/Oスレッドが実行されていません

スレーブのI/Oスレッドは、マスターのバイナリログから文を検索し、それをスレーブのリレーログ内に書き込みます。 このスレッドが実行されないと、スレーブはマスターからの最新データを検索できません。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

スレーブ設定が読み取り専用ではありません

スレーブを更新した結果、意図せずに、レプリケーションを壊したり、スレーブがマスターと一致しない状態を招くことがあります。 スレーブを更新した結果、意図せずに、レプリケーションを壊したり、スレーブがマスターと一致しない状態を招くことがあります。 スレーブを read_only にすると、スレーブはクライアントからの更新は受け付けずマスターからの更新のみを受け付けるようになるため有用です。 これにより不注意により更新される可能性が大幅に減少します

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブのリレーログ容量が非常に大きくなっています

スレーブがマスターから更新を受け取るとき、I/Oスレッドはリレーログとして知られるローカルファイルにデータを格納します。 スレーブのSQLスレッドはリレーログを読み込み、そこに含まれる更新を実行します。SQLスレッドがリレーログにあるすべての更新を実行してしまえばファイルは不要になり、ディスクスペースを確保するために削除することができます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブでリレーログの自動削除が設定されていません

スレーブがマスターから更新を受け取るとき、I/Oスレッドはリレーログとして知られるローカルファイルにデータを格納します。 スレーブのSQLスレッドはリレーログを読み込み、そこに含まれる更新を実行します。 SQLスレッドがリレーログにあるすべての更新を実行してしまえばファイルは不要になり、ディスクスペースを確保するために削除することができます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スレーブのSQLスレッドが実行されていません

スレーブのSQLスレッドは、スレッドのリレーログから文を読み込んで実行し、マスターと同期をとります。 このスレッドが実行されていないということは、スレーブはマスターから読み込んだ最新の変更を適用できませんし、スレーブへの検索結果にマスタでの最新の変更が反映されません。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

スレーブのSQLスレッドが、I/Oスレッドよりも古いリレーログから読み込んでいます

スレーブがマスターから更新を受け取るとき、I/Oスレッドはリレーログとして知られるローカルファイルにデータを格納します。 スレーブのSQLスレッドはリレーログを読み込み、そこに含まれる更新を実行します。 I/Oスレッドが現在書き込んでいるものよりも古いリレーログをSQLスレッドが読み込もうとしている場合、それはレプリケーションが遅延しかけていて、スレーブに送られたクエリの結果に最新の変更が反映されていない可能性があることを示しています。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレーブが大幅にマスターから遅れています

スレーブがマスターから大幅に遅延した場合、スレーブに指示されるクエリの結果が、マスターで実行された最新の変更を反映していない場合があります。

デフォルトの頻度 00:01:00

デフォルト自動クローズ有効？ yes

スレーブはリレーログスペースが空くのを待っています

スレーブのディスク容量が限られている場合、レプリケーションリレーログのサイズの上限を設定することができます。 上限に達すると、I/Oスレッドは、SQLスレッドの処理が追いついて未処理リレーログが削除されるまでマスターサーバからのバイナリログイベントの読み取りを停止します。 これによりMySQLのディスクが満杯になることは避けられますが、レプリケーションは遅延し、スレーブがマスターに追いつけなくなります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレーブにREPLICATION SLAVE権限を持つアカウントがありません

マスターが失敗し続けるような場合、スレーブの1つを新しいマスターとして使用することができます。 レプリケーションマスターとして動作するサーバにはREPLICATION SLAVE権限を持つアカウントが必要です（スレーブが接続できるように）。 使用するスレーブ上にこのアカウントを作成し、必要になった場合はマスターの代替とすることができます。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

スロークエリログが有効になっていません

スロークエリログにより、完了までに長時間かかったクエリを特定することができます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

SELECT *構文を含むストアードプロシージャが見つかりました

SQLコード作成のベストプラクティスによれば、クエリにはSELECT *が含まれるべきではありません。 理由は次の通りです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

ストアドルーチンが定義者より呼び出し者のセキュリティコンテキストで実行される

バグ18630が原因で、あるユーザが作成したストアドルーチンを、他のユーザにGRANT EXECUTEでアクセスできるようにした場合、そのユーザがルーチンの定義者の権限で実行できてしまいます。

このバグは後のバージョンのMySQLサーバで修正済みです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

シンボリックシンクが有効です

テーブルやデータベースをデータベースディレクトリから他の場所に移動してシンボリックリンクに置き換えることができます。 これを行うのは、たとえば、データベースを空き容量のあるファイルシステムに移動する場合や、テーブルを別のディスクに分散させてシステムのスピードを改善するといった場合です。

しかしながら、シンボリックリンクはセキュリティを損なう場合があります。 これはmysqlをルートで実行している場合、特に重要です。 サーバのデータディレクトリに書き込みアクセス権を持つ人は、システムのどのファイルでも削除できてしまうからです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

テーブルキャッシュが最適化されていません

MySQLはマルチスレッド対応なので、特定のテーブルに対して複数のクライアントが同時にクエリを発行することができます。 複数クライアントスレッドが同一テーブルに対して異なる状態を持つことに伴う問題を少しでも少なくするため、テーブルはスレッドごとに別々に開かれます。

テーブルキャッシュは開いているテーブルのファイルデスクリプタをキャッシュするのに使用され、ひとつのキャッシュが全クライアントによって共有されます。テーブルキャッシュサイズを大きくすると、mysqldが同時オープンするテーブルが増え、必要とされるテーブル開閉操作の数が減ります。Open_tables値が table_cache値に近づいていく場合、パーフォーマンス上の問題が発生している可能性があります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

サービス開始時のテーブルキャッシュ設定が低すぎます

テーブルキャッシュサイズにより、サーバで1度に開くことのできるテーブル数が制御されます。テーブルキャッシュ制限を超えた場合、テーブルキャッシュサイズが小さすぎると考えられます。 MySQLはテーブルの開閉を必要に応じて行いますが、テーブルキャッシュ設定が低すぎると、オブジェクトへのアクセスに対応するためにMySQLは絶え間なくテーブル開閉を繰り返すことになります。

サービス開始後最初の3時間に開かれたテーブル数がテーブルキャッシュ制限を超えた場合、テーブルキャッシュサイズが小さすぎると考えられます。

デフォルトの頻度 00:30:00

デフォルト自動クローズ有効？ no

テーブルロックの競合が多すぎます

総ロック数に対し、ロックを確保するために待機しているテーブル操作の割合が高いとパーフォーマンスが低下する可能性があります。これが起こるのは行レベルでロックするストレージエンジンではなく、MyISAMなどのようにテーブルレベルのロックをサポートするストレージエンジンを使用している場合です。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

テーブルスキャンが多すぎます

対象のサーバはインデックスを効果的に使用していないようです。Handler_read_rnd_nextおよびHandler_read_rnd 両方の値が、（これらは全テーブルスキャンにより読み込まれた行数が反映されます。） Handler_read_keyやHandler_read_nextなどの全行アクセスを示すHandler変数の合計と比較して高くなっています。 テーブルおよびクエリを、インデックスの適切な使用という見地から見直してください。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

プライマリまたは固有キーのないテーブルがあります

リレーショナルテーブルのプライマリまたは固有キーは、テーブル内の各レコードを識別します。非常に特殊な場合を除き、すべてのデータベーステーブルは、1 つまたは 複数の列を、プライマリまたは固有のキーとして指定し、通常 1つを宣言します。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

一時テーブルのディスク使用率が大きすぎます

一時テーブルの構築に、 tmp_table_size または max_heap_table_sizeを超えたスペースが必要とされる場合、MySQLはサーバのtmpdirディレクトリにディスクベースのテーブルを作成します。また、TEXTまたはBLOBカラムを含むテーブルは自動的にディスク上に置かれます。

性能の観点からすると、巨大なテンポラリテーブルがディスク上に作成される場合を除き、テンポラリテーブルは概ねメモリ上に作成されるべきです。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレッドキャッシュが有効になっていません

MySQLデータベース・サーバへの各接続は、それ自身のスレッド内で実行されます。 スレッドの作成には時間がかかるため、接続をクローズするときにスレッドを強制終了せずにスレッドキャッシュ内に保持し、後で新しい接続のために使用することができます。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

スレッドキャッシュサイズが最適化されていないようです

MySQLデータベースサーバへの各接続は、それ自身のスレッド内で実行されます。 スレッドの作成には時間がかかるため、接続をクローズするときにスレッドを強制終了せずにスレッドキャッシュ内に保持し、後で新しい接続のために使用することができます。

デフォルトの頻度

デフォルト自動クローズ有効？ no

同時に実行されるクエリが多すぎます

アクティブなクエリが多すぎるということはサーバの負荷が高い状態であることを示します。ロックの競合や最適化されていないSQLクエリがある兆候かも知れません。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

UDF サポートを使用して任意のコードを実行できます

バージョン 4.1 および 5.0 においては、ユーザ定義関数(UDF)はシステムライブラリのパスからロードされます(例 /usr/lib)。現在使用しているセキュリティフィルタは、既存のシステムライブラリを使用した攻撃に正しく対処しないことが分かりました。その結果、権限を持ったユーザが、任意の実行コードにアクセスする可能性があります。そのため、信用のないリモートのユーザが MySQL に対して DBA 権限を持つ場合、積極的に UDF を使用していないシステム上において、この問題が悪用される可能性があります。この問題から適切にシステムを保護するために、新しい変数 plugin_dirが導入され、プログインをロードする場所を別にディレクトリに指定することができます。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

安全でない場所からロードされたユーザ定義関数(UDF)です

ユーザ定義関数(User Defined Functions:UDFs) によって、MySQLサーバの機能を拡張することができますが、それらが安全でない場所からロードできる場合はシステムを危険にさらすことになります。

この問題を解決するために、プラグインをロードする場所を指定できる plugin_dir変数が導入されました。値が空でない場合、UDF オブジェクトファイルはそのディレクトリからロードされなくてはなりません。値が空の場合、UDF オブジェクトファイルは、システムのダイナミックリンカから検索可能な任意の場所からロードすることができ、既存のシステムライブラリを使用した攻撃から正しくシステムを保護できません。その結果、権限を持ったユーザが、任意の実行コードにアクセスする可能性があります。そのため、信用のないリモートのユーザが MySQL に対して DBA 権限を持つ場合、積極的に UDF を使用していないシステム上において、この問題が悪用される可能性があります。

デフォルトの頻度 12:00:00

デフォルト自動クローズ有効？ no

現在の表のカラム更新権限にオーバーライドされたビューの使用

バグ#27878が原因で、ビューの使用により, テーブルの与えられたカラムにだけ更新権限を持つユーザが、テーブルのどんなカラムも更新可能となる。たとえビューがSQL SECURITY INVOKERで定義されていたとしても。また、ビューの利用がユーザに、他のデータベースのテーブルの更新権を取得することを可能にしてしまう。

このバグは後のバージョンのMySQLサーバでは修正済みです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

SQL SECURITY INVOKERを使って宣言されたストアドルーチンを走らせることによってユーザが権限を取得できる

バグ#27337が原因で、もしストアドルーチンがSQL SECURITY INVOKERを使って宣言されていた場合、それを起動したユーザは権限を取得できてしまう。例えば、あるデータベースでCREATE権限を持たないユーザが、ストアドルーチンを起動した後権限を得てしまう。

このバグは後のバージョンのMySQLで修正済みです。

デフォルトの頻度 06:00:00

デフォルト自動クローズ有効？ no

存在しないデータベースに対して権限を持ったユーザです

データベースをドロップする際、そのデータベースに対して定義された権限は自動的にドロップされることはありません。将来的に同じ名前を持つデータベースが作成された時に、そのユーザが意図せずに権限を得てしまうという潜在的なセキュリティの問題に繋がります。

デフォルトの頻度 00:05:00

デフォルト自動クローズ有効？ no

存在しないテーブルの権限を持つユーザです

テーブルが削除されても、そのテーブルに対するユーザの権限は自動的に削除されません。これは、セキュリティ上の設計で、その後意図せずに同名のテーブルが同じデータベース内に作成された場合に、そのユーザが再びその権限を取得します。

デフォルトの頻度

デフォルト自動クローズ有効？

パーティション化されたテーブルにALTER権限だけ持つユーザが、SELECT権限情報を取得できる

バグ#23675が原因で、パーティション化されたテーブルにALTER権限だけ持つユーザが、SELECT権限情報が必要なその表情報を取得できてしまいます。

このバグは後のバージョンのMySQLで修正済みです。

デフォルトの頻度

デフォルト自動クローズ有効？

ユーザがMySQLサーバ上のすべてのデータベースを見ることが可能です

SHOW DATABASES権限は、MySQLサーバ上のすべてのデータベースを見る必要のあるユーザに対してのみ許可されるべきです。MySQLサーバを--skip-show-database オプション付きで起動し、SHOW DATABASES権限を明示的に許可されていないユーザにはSHOW DATABASES文を使用できないようにすることを推奨します。

注意： CREATE TEMPORARY TABLESやLOCK TABLESといったグローバル権限を許可されたユーザは、サーバが--skip-show-databaseオプションを有効にして起動されている場合を除き、自動的にデータベースを表示する権限が付与されます。 DBAは、アプリケーションで一時テーブルを利用している場合、このことを認識するようにしてください。DBAは、アプリケーションで一時テーブルを利用している場合、このことを認識するようにしてください。

デフォルトの頻度

デフォルト自動クローズ有効？

警告がログされていません

MySQL サーバに発生したエラーはすべてエラーログにログされますが、警告は、og_warningsが　0 より大きい値に設定された時のみログされます。警告がログされないと、失敗した接続やその他の通信エラーに関する重要な情報を得ることができません。これはレプリケーションを使用している場合に特に重要で、ネットワークの障害や再接続に関するメッセージなどを得ることができます。

デフォルトの頻度

デフォルト自動クローズ有効？

InnoDBのXA分散トランザクションサポートが有効になっています

XA分散トランザクションサポートは、デフォルトでオンに設定されまています。 この機能を使用しない場合、この機能により、トランザクションごとに余分のfsyncの実行を追加し、パーフォーマンスに悪影響を与えることに注意してください。

デフォルトの頻度

デフォルト自動クローズ有効？