MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.4.4 バイナリログ
バイナリログには、テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述する「イベント」が格納されます。 また、行ベースのロギングが使用される場合を除き、(一致する行のない DELETE などの) 潜在的に変更を行おうとしたステートメントについてのイベントも格納されます。 バイナリログには、データを更新した各ステートメントに要した時間に関する情報も格納されます。 バイナリログには 2 つの重要な目的があります。 レプリケーションの場合、レプリケーションソースサーバー上のバイナリログは、レプリカに送信されるデータ変更のレコードを提供します。 ソースは、バイナリログに含まれている情報をレプリカに送信します。このレプリカは、それらのトランザクションを再現して、ソースで行われたものと同じデータ変更を行います。 セクション17.2「レプリケーションの実装」を参照してください。 ある特定
MySQL :: Download Connector/J
MySQL Connector/J is the official JDBC driver for MySQL. MySQL Connector/J 8.0 and higher is compatible with all MySQL versions starting with MySQL 5.7. Additionally, MySQL Connector/J 8.0 and higher supports the new X DevAPI for development with MySQL Server 8.0 and beyond. Online Documentation: MySQL Connector/J Installation Instructions Documentation MySQL Connector/J X DevAPI Reference Change
MySQL :: MySQL 8.4 Reference Manual :: 12.9.1 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)
For a BMP character, utf8mb4 and utf8mb3 have identical storage characteristics: same code values, same encoding, same length. For a supplementary character, utf8mb4 requires four bytes to store it, whereas utf8mb3 cannot store the character at all. When converting utf8mb3 columns to utf8mb4, you need not worry about converting supplementary characters because there are none. utf8mb4 is a superset
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.8.2 EXPLAIN ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.6.1.5 MyISAM から InnoDB へのテーブルの変換
信頼性とスケーラビリティを向上させるために InnoDB に変換する MyISAM テーブルがある場合は、変換する前に次のガイドラインとヒントを確認してください。 以前のバージョンの MySQL で作成されたパーティション化された MyISAM テーブルは、MySQL 8.0 と互換性がありません。 このようなテーブルは、パーティション化を削除するか、InnoDB に変換して、アップグレード前に準備する必要があります。 詳細は、セクション24.6.2「ストレージエンジンに関連するパーティショニング制限」を参照してください。 MyISAM テーブルから移行するときに、結果をキャッシュする際に必要でなくなったメモリーが解放されるように、key_buffer_size 構成オプションの値を小さくします。 InnoDB テーブル用のキャッシュメモリー割り当てと同様の役割を担う innodb_buf
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.18.1 InnoDB バックアップ
安全なデータベース管理の鍵は、定期的なバックアップを作成することです。 データ量、MySQL サーバーの数およびデータベースワークロードに応じて、これらのバックアップ手法を単独または組み合せて使用できます: MySQL サーバーの停止中にファイルをコピーして hot backup with MySQL Enterprise Backup; cold backup; logical backup with mysqldump for small data volumes or record the structure of schema objects. ホットバックアップとコールドバックアップは、実際のデータファイルをコピーする physical backups です。これは、リストアを高速化するために mysqld サーバーで直接使用できます。 InnoDB データをバックアップするには
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.3.4 BLOB 型と TEXT 型
BLOB はさまざまな容量のデータを保持できる大きなバイナリオブジェクトです。 BLOB 型は、TINYBLOB、BLOB、MEDIUMBLOB、および LONGBLOB の 4 つがあります。 これらの違いは、保持できる値の最大長だけです。 TEXT 型は、TINYTEXT、TEXT、MEDIUMTEXT、および LONGTEXT の 4 つがあります。 これらは 4 つの BLOB 型に対応し、最大長とストレージ要件は同じです。 セクション11.7「データ型のストレージ要件」を参照してください。 BLOB 値はバイナリ文字列 (バイトの文字列) として扱われます。 これらには binary 文字セットと照合順序があり、比較とソートはカラム値のバイトの数値に基づきます。 TEXT 値は非バイナリ文字列 (文字の文字列) として扱われます。 これらには binary 以外の文字セットがあり
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.3.3 BINARY および VARBINARY 型
BINARY および VARBINARY 型は、非バイナリ文字列ではなくバイナリ文字列を格納する点を除き、CHAR および VARCHAR と似ています。 つまり、文字列ではなくバイト文字列が格納されます。 これは、binary 文字セットと照合順序があり、比較とソートは値のバイトの数値に基づいていることを意味します。 BINARY および VARBINARY の最大許容長は、CHAR および VARCHAR の場合と同じですが、BINARY および VARBINARY の長さは文字ではなくバイト単位で測定されます。 BINARY および VARBINARY データ型は CHAR BINARY および VARCHAR BINARY データ型とは異なります。 後者の型は、BINARY 属性によってカラムがバイナリ文字列カラムとして扱われることはありません。 代わりに、カラム文字セット (また
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.3.2 CHAR および VARCHAR 型
CHAR 型と VARCHAR 型は似ていますが、格納および取得方法が異なります。 また、最大長と、末尾のスペースが保持されるかどうかという点でも異なります。 CHAR 型と VARCHAR 型には、格納する最大文字数を表す長さが宣言されています。 たとえば、CHAR(30) には最大 30 文字を格納できます。 CHAR カラムの長さは、テーブルを作成したときに宣言した長さに修正されます。 この長さには、0 から 255 までの任意の値を指定できます。 CHAR 値は格納されると、指定された長さになるように右側がスペースで埋められます。 PAD_CHAR_TO_FULL_LENGTH SQL モードが有効になっていないかぎり、CHAR 値が取り出されるときに、末尾のスペースが削除されます。 VARCHAR カラム内の値は可変長の文字列です。 長さは 0 から 65,535 までの値で指定
MySQL (int,char)
MySQL では、複数のカテゴリの SQL データ型がサポートされています: 数値型、日時型、文字列 (文字およびバイト) 型、空間型および JSON データ型。 この章では、各カテゴリのタイプのプロパティの概要と詳細、およびデータ型の記憶域要件の概要について説明します。 最初の概要は意図的に簡単です。 値を指定できる許容形式など、特定のデータ型に関する追加情報は、より詳細な説明を参照してください。 データ型の説明では、次の規則を使用しています。 整数型の場合、M は最大表示幅を示します。 浮動小数点型と固定小数点型の場合、M は格納可能な桁数の合計 (精度) です。 文字列型の場合は、M は最大長です。 M の許可される最大値は、データ型によって異なります。 D は、浮動小数点型と固定小数点型に適用され、小数点以下の桁数 (スケール) を表します。 指定可能な最大値は 30 ですが、M−
MySQL :: MySQL 8.0 リファレンスマニュアル :: 16.2 MyISAM ストレージエンジン
各 MyISAM テーブルは、ディスク上の 2 つのファイルに格納されます。 そのファイル名はテーブル名で始まり、ファイルタイプを示す拡張子が付きます。 データファイルには .MYD (MYData) 拡張子が付きます。 インデックスファイルには .MYI (MYIndex) 拡張子が付きます。 テーブル定義は、MySQL データディクショナリに格納されます。 MyISAM テーブルが必要であることを明示的に指定するには、ENGINE テーブルオプションで指定します。 CREATE TABLE t (i INT) ENGINE = MYISAM; MySQL 8.0 では通常、InnoDB がデフォルトエンジンであるため、ENGINE を使用して MyISAM ストレージエンジンを指定する必要があります。 mysqlcheck クライアントか myisamchk ユーティリティーで MyI
MySQL :: MySQL 8.0 リファレンスマニュアル :: C インデックス
シンボル | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z シンボル [索引の先頭] ! 非推奨となった機能, MySQL 8.0 で非推奨となった機能 ! (論理 NOT), 論理演算子 != (等しくない), 比較関数と演算子 ", スキーマオブジェクト名 " (二重引用符), 文字列リテラル, JSON 値を変更する関数 %, 算術演算子 % (modulo), 数学関数 % (ワイルドカード文字), 文字列リテラル & & (論理 AND), 論理演算子 & (ビット単位 AND), MySQL 5.7 とのビット操作の非互換性 && 非推奨となった機能, MySQL 8.0 で非推奨となった機能 'on clause'のカラ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.2 スキーマオブジェクト名
データベース、テーブル、インデックス、カラム、エイリアス、ビュー、ストアドプロシージャ、パーティション、テーブルスペース、リソースグループ、その他のオブジェクト名など、MySQL 内の特定のオブジェクトは識別子と呼ばれます。 このセクションでは、MySQL で使用可能な識別子の構文について説明します。セクション9.2.1「識別子の長さ制限」 は、各タイプの識別子の最大長を示します。セクション9.2.3「識別子の大文字と小文字の区別」 では、大/小文字が区別される識別子のタイプとその条件について説明します。 識別子は引用符で囲むことも囲まないこともあります。 識別子に特殊文字が含まれている場合、または識別子が予約語である場合、その識別子を参照するときは必ず引用符で囲む必要があります。 (例外: 修飾名内でピリオドのあとに続く予約語は識別子である必要があるため、引用符で囲む必要はありません。)
MySQL :: MySQL 5.1 リファレンスマニュアル :: 2.11.1 MySQL 5.0 から 5.1 へのアップグレード
以下のリストはアプリケーションに影響を及ぼす可能性があり MySQL 5.1 にアップグレードする際に注意を要する項目をリストに纏めたものです。. 設定の変更: MySQL 5.1.11 以前で MySQL をソースから SSL サポート付きでビルドする場合、configure を --with-openssl あるいは --with-yassl オプションのいずれかで実行します。MySQL 5.1.11 では、それらのオプションは両方とも --with-ssl オプションで置き換えられています。デフォルトで、--with-ssl でバンドルした yaSSL ライブラリを使用できます。OpenSSL を選択するには、オプションを --with-ssl=path として与え、そこでは path はディレクトリで OpenSSL のヘッダーファイルおよびライブラリが格納されています。 非互換の
MySQL :: MySQL 5.1 リファレンスマニュアル :: 2.11.2 MySQL データベースの他のマシンへのコピー
.frm、.MYI、および .MYD ファイルを MyISAM テーブルに同じフローティング ポイント フォーマットをサポートしている異なるアーキテクチャ間でコピーでします。(MySQL はバイト スワッピング問題を処理します。.)項13.4. 「MyISAM ストレージエンジン」 参照。 データベースを異なるアーキテクチャ間で移動する場合、mysqldump を使用して SQL ステートメントを含むファイルを作成します。次にそのファイルを別のマシンに転送して mysql クライアントの入力として扱います。 利用できるオプションを表示するには mysqldump --help を使用します。データを新しいバージョンの MySQL に移動するには mysqldump --opt を使用して最適化を活用することによってさらに小さくて迅速に処理が可能なダンプ ファイルを作成します。 データベース
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.11.4 テーブルのデフラグ
セカンダリインデックスへのランダムな挿入やセカンダリインデックスからのランダムな削除によって、インデックスが断片化される場合があります。 断片化とは、ディスク上のインデックスページの物理的な順序がページ上のレコードのインデックス順序とかけ離れているか、またはインデックスに割り当てられた 64 ページのブロック内に未使用のページが多数存在することを示します。 断片化の 1 つの現象として、あるテーブルが占めている領域が、本来占めている「はずの」領域より大きいことがあります。 それが正確にどの程度かを判定するのは困難です。 すべての InnoDB データおよびインデックスは B-trees に格納され、その fill factor は 50% から 100% まで異なる場合があります。 断片化の別の現象として、次のようなテーブルスキャンにかかる時間が、本来かかる「はずの」時間より長いことがあり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.1 バックアップ用にレプリケーションを使用する
MySQL :: MySQL Enterprise Backup ユーザーズガイド (バージョン 3.11)
MySQL :: MySQL Enterprise Monitor 3.0.18 マニュアル
MySQL :: MySQL 8.4 Reference Manual :: 19.1.6.4 Binary Logging Options and Variables