I think most people will agree that downloading RPMs from a website is kind of old fashioned when there are yum repos. After a number of user requests, we have now launched the official yum repos for MySQL. Can’t wait? Neither can I. On a fresh install: Download a setup package for your distribution from http://dev.mysql.com/downloads/repo yum localinstall mysql-community-release-distro-release.no
多くの暗号化関数および圧縮関数では、結果に任意のバイト値が含まれている可能性のある文字列が返されます。 これらの結果を格納する場合は、VARBINARY または BLOB バイナリ文字列データ型のカラムを使用します。 これにより、バイナリ以外の文字列データ型 (CHAR, VARCHAR, TEXT) を使用している場合など、データ値を変更する可能性がある後続の領域削除または文字セット変換の潜在的な問題を回避できます。 一部の暗号化関数は ASCII 文字の文字列を返します: MD5(), SHA(), SHA1(), SHA2(), STATEMENT_DIGEST(), STATEMENT_DIGEST_TEXT()。 戻り値は、character_set_connection および collation_connection システム変数によって決定される文字セットと照合順序を持つ文
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
ORDER BY と組み合わされた DISTINCT では多くの場合に一時テーブルが必要です。 DISTINCT では GROUP BY を使用できるため、MySQL が ORDER BY または HAVING 句内の選択したカラムの部分でないカラムをどのように処理するかを学んでください。 セクション12.20.3「MySQL での GROUP BY の処理」を参照してください。 ほとんどの場合、DISTINCT 句は GROUP BY の特殊な例と考えることができます。 たとえば、次の 2 つのクエリーは同等です。 SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > const; SELECT c1, c2, c3 FROM t1 WHERE c1 > const GROUP BY c1, c2, c3; この同等性のため、GROUP BY クエリ
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
数値データ型のサマリーについて説明します。数値型のプロパティーおよびストレージ要件の追加情報については、セクション11.2「数値型」およびセクション11.7「データ型のストレージ要件」を参照してください。 M は整数型の最大表示幅を示します。最大表示幅は 255 です。セクション11.2「数値型」で説明しているように、表示幅はその型に含めることができる値の範囲とは関係ありません。浮動小数点型と固定小数点型の場合、M は格納可能な桁数の合計です。 数値カラムに対して ZEROFILL を指定すると、MySQL は自動的にそのカラムに UNSIGNED 属性を追加します。 UNSIGNED 属性を許可している数値データ型は、SIGNED も許可します。ただし、このデータ型はデフォルトで符号付きになっているため、SIGNED 属性を指定しても効果はありません。 SERIAL は BIGINT U
整数型 (真数値) - INTEGER、INT、SMALLINT、TINYINT、MEDIUMINT、BIGINT
Section Navigation [Toggle] 13.5.11 InnoDB パフォーマンス チューニング ヒント13.5.11.1 SHOW ENGINE INNODB STATUS と InnoDB モニタ InnoDB は InnoDB 内部の状態についての情報をプリントする InnoDB モニタを含んでいます。ご自分の SQL クライアントにスタンダード InnoDB モニタのアウトプットをフェッチする為に、いつでも SHOW ENGINE INNODB STATUS SQL ステートメントを利用する事ができます。 この情報は性能調整をするうえで役立ちます。(もし mysql インタラクティブ SQL クライアントを利用しているなら、\G を通常のセミコロン ステートメント ターミネータと置き換えれば、アウトプットはより読みやすくなります。)InnoDB ロック
"The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect Oracle's product development plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material, code, or functionality, and should not be reli
各 InnoDB テーブルとそのインデックスをそれ自体のファイル内に格納する事ができます。この特徴は、実際に各テーブルがそのテーブルスペースを持つ為 「multiple tablespaces」 と呼ばれています。 複数のテーブルスペースを利用する事は、特定のテーブルを別々の物理ディスクに移動したり、単一テーブルのバックアップを残りの InnoDB テーブルの利用を邪魔する事なく、素早く復元したいユーザにとって、有益な物です。 このラインを my.cnf の [mysqld] セクションに追加する事で、複数のテーブルスペースを有効にする事ができます: [mysqld] innodb_file_per_table サーバを再起動した後、InnoDB はテーブルが属するデータベース ディレクトリ内にある、それ自体のファイル tbl_name.ibd 内に、それぞれの新しく作成されたテーブルを格
MySQL 5.1 はサーバ サイドのプリペアド ステートメントへのサポートを提供します。妥当なクライアント プログラムインターフェースを利用するという条件で、このサポートは MySQL 4.1 内でインプリメントされた有効なクライアント/サーバ バイナリ プロトコルを駆使します。インターフェース候補は、MySQL C API クライアント ライブラリ(C プログラムの為の物)、MySQL コネクタ/J(プログラムの為の物)、そして MySQL コネクタ/NET です。例えば、C API はそのプリペアド ステートメント API を構成する関数呼び出しのセットを提供します。詳しくは 項23.2.4. 「準備されたC APIステートメント。」 を参照してください。別の言語インターフェースは、バイナリ プロトコルを C クライアント ライブラリ内でリンクさせて利用するプリペアド ステートメント
ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。 別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。 カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。 ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。 このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。 情報はカテゴリまたはストレージエンジンごとに示します。 テーブルの内部表現の最大行サイズは 65,535 バイトで
スケールアウトソリューション - 複数のレプリカに負荷を分散して、パフォーマンスを向上させます。 この環境では、すべての書込みおよび更新がソースサーバーで実行される必要があります。 ただし、1 つまたは複数のレプリカで読み取りが行われる場合があります。 このモデルでは、(ソースが更新専用であるため) 書込みのパフォーマンスを向上させる一方で、レプリカの数の増加に伴って読取り速度を大幅に向上させることができます。 データセキュリティ - レプリカはレプリケーションプロセスを一時停止できるため、対応するソースデータを破損させることなくレプリカでバックアップサービスを実行できます。 アナリティクス - ライブデータはソースで作成できますが、情報の分析はソースのパフォーマンスに影響を与えることなくレプリカで実行できます。 長距離データ分散 - レプリケーションを使用すると、ソースに永続的にアクセス
概要 これは MySQL リファレンスマニュアルです。 MySQL 8.0 から 8.0.25、および NDB のバージョン 8.0 から 8.0.25-ndb-8.0.25 に基づく NDB Cluster リリースについてそれぞれ説明します。 まだリリースされていない MySQL バージョンの機能のドキュメントが含まれている場合があります。 リリースされたバージョンの詳細は、「MySQL 8.0 リリースノート」を参照してください。 MySQL 8.0 の機能. このマニュアルでは、MySQL 8.0 のエディションによっては含まれていない機能について説明します。このような機能は、ご自身にライセンス付与されている MySQL 8.0 のエディションに含まれていない場合があります。 MySQL 8.0 の使用しているエディションに含まれる機能に関する質問がある場合は、MySQL 8.0
MySQL において、データベースはデータディレクトリ内のディレクトリに対応しています。 データベース内の各テーブルも、データベースディレクトリ内の少なくとも 1 つ (ストレージエンジンによってはそれ以上) のファイルに対応しています。 トリガーもファイルに対応しています。 この結果、基になるオペレーティングシステムで大文字と小文字が区別されるかどうかが、データベース名、テーブル名、およびトリガー名で大文字と小文字が区別されるかどうかに影響します。 つまり、このような名前は Windows では大文字と小文字が区別されませんが、ほとんどの種類の Unix では大文字と小文字が区別されます。 特に重要な例外は、Unix ベースであるが、大/小文字を区別しないデフォルトのファイルシステムタイプ (HFS+) を使用する macOS です。 ただし、macOS は UFS ボリュームもサポート
このセクションでは、InnoDB テーブル スペースがスペースを使いきってしまったり、ログ ファイルのサイズを変更したい時に何ができるか説明しています。 InnoDB テーブル スペースのサイズを増やす一番簡単な方法は、最初からこれを自動拡大として設定する事です。テーブル スペース定義内の最後のデータ ファイルの autoextend 属性を指定してください。すると InnoDB は領域を使い切ってしまった時、そのファイルのサイズを自動的に8MB インクリメント増やします。インクリメントサイズは、MBで計られる innodb_autoextend_increment システム変数の値を設定する事で変更できます。 または、別のデータ ファイルを追加する事でテーブル スペースのサイズを増やす事ができます。これを行う為には、MySQL サーバを閉じ、innodb_data_file_path の
アカウントを作成するためのステートメント (CREATE USER や GRANT など) を使用する。これらのステートメントを発行すると、サーバーによって付与テーブルへの適切な変更が行われます。 INSERT、UPDATE、DELETE などのステートメントを使用して、MySQL 付与テーブルを直接操作する。 アカウント作成のステートメントを使用する方が、付与テーブルを直接操作するよりも簡潔で、エラーの発生率も低いため、推奨される方法です。CREATE USER および GRANT については、セクション13.7.1「アカウント管理ステートメント」で説明されています。 アカウントを作成するためのもう 1 つのオプションは、GUI ツール MySQL Workbench を使用する方法です。または、MySQL アカウント管理の機能を提供する使用可能な複数のサードパーティープログラムのいずれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く