MySQL AB :: MySQL 4.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 :: MySQL yum repositories
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
MySQL :: MySQL 8.0 リファレンスマニュアル :: 24.6 パーティショニングの制約と制限
このセクションでは、MySQL パーティショニングサポートでの現在の制約と制限について説明します。 禁止されている構造体. 次の構造体はパーティショニング式で許可されません。 パーティショニング式で許可される SQL 関数のリストについては、セクション24.6.3「関数に関連するパーティショニング制限」を参照してください。 算術および論理演算子. 算術演算子 +、-、および * の使用は、パーティショニング式で許可されます。 ただし、結果は整数値または NULL である必要があります (この章のほかの場所で説明しているように、[LINEAR] KEY パーティショニングの場合を除きます。詳細は、セクション24.2「パーティショニングタイプ」を参照してください)。 DIV 演算子もサポートされています。/演算子は使用できません。 ビット演算子 |、&、^、<<、>>、および ~ はパーティシ
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.6.7 InnoDB テーブル上の制限
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.5.2 MySQL バージョン間のレプリケーション互換性
MySQL は、あるリリースシリーズから次の上位リリースシリーズへのレプリケーションをサポートしています。 たとえば、MySQL 5.6 を実行しているソースから MySQL 5.7 を実行しているレプリカ、MySQL 5.7 を実行しているソースから MySQL 8.0 を実行しているレプリカなどにレプリケートできます。 ただし、ソースがステートメントを使用しているか、レプリカで使用されている MySQL のバージョンでサポートされなくなった動作に依存している場合、古いソースから新しいレプリカにレプリケートするときに問題が発生することがあります。 たとえば、64 文字を超える外部キー名は、MySQL 8.0 からサポートされなくなりました。 複数のソースを含むレプリケーション設定では、ソースまたはレプリカ MySQL サーバーの数に関係なく、複数の MySQL Server バージョンの
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.1.2 レプリカからの RAW データのバックアップ
通常、レプリカ MySQL サーバーのデータディレクトリ全体をバックアップする必要があります。 データをリストアしてレプリカとして操作できるようにするには (レプリカに障害が発生した場合など)、データに加えて、レプリカ接続メタデータリポジトリと適用者メタデータリポジトリ、およびリレーログファイルが必要です。 これらのアイテムは、レプリカデータのリストア後にレプリケーションを再開するために必要です。 MySQL 8.0 のデフォルトであるレプリカ接続メタデータリポジトリおよび適用機能メタデータリポジトリ (セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照) にテーブルが使用されている場合、これらのテーブルはデータディレクトリとともにバックアップされます。 非推奨のリポジトリにファイルが使用されている場合は、それらを個別にバックアップする必要があります。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.2.1.16 ORDER BY の最適化
このセクションでは、MySQL が ORDER BY 句を満たすためにインデックスを使用できるタイミング、インデックスを使用できない場合に使用される filesort 操作、および ORDER BY に関するオプティマイザから使用可能な実行計画情報について説明します。 セクション8.2.1.19「LIMIT クエリーの最適化」 で説明されているように、LIMIT を使用する場合と使用しない場合で ORDER BY が異なる順序で行を返すことがあります。 場合によっては、MySQL でインデックスを使用して ORDER BY 句を満たし、filesort 操作の実行に伴う余分なソートを回避できます。 インデックスのすべての未使用部分と追加の ORDER BY カラムが WHERE 句の定数であるかぎり、ORDER BY がインデックスと完全に一致しない場合でもインデックスを使用できます。 ク
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.2.3 レプリケーションスレッド
バイナリログダンプスレッド. ソースは、レプリカの接続時にバイナリログの内容をレプリカに送信するスレッドを作成します。 このスレッドは、ソース上の SHOW PROCESSLIST の出力で Binlog Dump スレッドとして識別できます。 バイナリログダンプスレッドは、レプリカに送信される各イベントを読み取るために、ソースバイナリログのロックを取得します。 イベントが読み取られるとすぐに、イベントがレプリカに送信される前でもロックが解除されます。 レプリケーション I/O スレッド. レプリカサーバーで START REPLICA | SLAVE ステートメントが発行されると、レプリカは I/O スレッドを作成します。このスレッドはソースに接続し、バイナリログに記録された更新を送信するように要求します。 レプリケーション I/O スレッドは、ソース Binlog Dump スレッドが
MySQL :: MySQL 8.0 リファレンスマニュアル :: B.3.2.2 [ローカルの] MySQL サーバーに接続できません
UNIX 上の MySQL クライアントは mysqld サーバーに 2 つの方法で接続できます。UNIX ソケットファイルを使用してファイルシステム内のファイル (デフォルトは /tmp/mysql.sock) を介して接続するか、TCP/IP を使用してポート番号を介して接続します。 UNIX ソケットファイルでの接続は TCP/IP よりも高速ですが、同じコンピュータ上にあるサーバーに接続するときにのみ使用できます。 UNIX ソケットファイルは、ホスト名を指定しない場合、または特殊なホスト名 localhost を指定する場合に使用されます。 MySQL サーバーが Windows 上で実行されている場合は、TCP/IP を使用して接続できます。 named_pipe システム変数を有効にしてサーバーを起動した場合、サーバーが実行されているホストでクライアントを実行していれば、名前
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.11.4 テーブルのデフラグ
セカンダリインデックスへのランダムな挿入やセカンダリインデックスからのランダムな削除によって、インデックスが断片化される場合があります。 断片化とは、ディスク上のインデックスページの物理的な順序がページ上のレコードのインデックス順序とかけ離れているか、またはインデックスに割り当てられた 64 ページのブロック内に未使用のページが多数存在することを示します。 断片化の 1 つの現象として、あるテーブルが占めている領域が、本来占めている「はずの」領域より大きいことがあります。 それが正確にどの程度かを判定するのは困難です。 すべての InnoDB データおよびインデックスは B-trees に格納され、その fill factor は 50% から 100% まで異なる場合があります。 断片化の別の現象として、次のようなテーブルスキャンにかかる時間が、本来かかる「はずの」時間より長いことがあり
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.3.4 OPTIMIZE TABLE ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.6.3 AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか
Section Navigation [Toggle] 13.5.6 InnoDB テーブルの作成と利用13.5.6.1 異なる API と共に InnoDB 内でトランザクションをどのように利用するか 13.5.6.2 MyISAM テーブルを InnoDB に変換する 13.5.6.3 AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか 13.5.6.4 FOREIGN KEY 制約 13.5.6.5 InnoDB と MySQL 複製 もし InnoDB テーブルに AUTO_INCREMENT カラムを指定すると、InnoDB データ ディレクトリ内のテーブル ハンドルは、カラムに新しい値を割り当てるのに利用される自動インクリメント カウンタと呼ばれる特別なカウンタを含みます。このカウンタは、ディスク上には格納されず、主メモリ内だけに格納されま
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.11.1 内部ロック方法
このセクションでは、内部ロック、つまり複数のセッションによるテーブル内容の競合を管理するために、MySQL サーバー自体の内部で実行されるロックについて説明します。 この種類のロックは、完全にサーバーによって実行され、ほかのプログラムは関与しないため、内部です。 ほかのプログラムによって MySQL ファイルに対して実行されるロックについては、セクション8.11.5「外部ロック」を参照してください。 MySQL は InnoDB テーブルに行レベルロックを使用して、複数のセッションによる同時書き込みアクセスをサポートし、それらを複数ユーザー、高度な並列性、および OLTP アプリケーションに適したものにします。 単一の InnoDB テーブルに対して複数の同時書込み操作を実行する場合に deadlocks を回避するには、データ変更ステートメントがトランザクションの後半にある場合でも、変更
MySQL :: MySQL 8.0 リファレンスマニュアル :: B.3.2.8 パケットが大きすぎます
通信パケットは、MySQL サーバーに送信される単一の SQL ステートメント、クライアントに送信される単一行、またはソースレプリケーションサーバーからレプリカに送信されるバイナリログイベントです。 MySQL 8.0 Server およびクライアント間で転送可能なパケットの最大サイズは 1G バイトです。 MySQL クライアントまたは mysqld サーバーが max_allowed_packet バイトより大きいパケットを受け取ると、ER_NET_PACKET_TOO_LARGE エラーが発行され、接続が失われます。 一部のクライアントでは、パケットが大きすぎる場合、「クエリー中に MySQL サーバーへの接続が失われました」というエラーを受け取ることもあります。 クライアントとサーバーの両方にそれぞれ max_allowed_packet 変数があるため、大きなパケットを処理する場
MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.6.10 mysqlhotcopy — データベースバックアッププログラム
mysqlhotcopy はもともと Tim Bunce によって書かれ、提供された Perl スクリプトです。FLUSH TABLES、LOCK TABLES、および cp または scp を使用してデータベースのバックアップを作成します。データベースまたは単一のテーブルのバックアップを作成するための高速な方法ですが、データベースディレクトリが置かれているのと同じマシンでしか実行できません。mysqlhotcopy は MyISAM テーブルおよびARCHIVE テーブルのみに機能します。Unix で実行されます。 mysqlhotcopy を使用するには、バックアップを行うテーブルのファイルへの読み取りアクセス、これらのテーブルの SELECT 権限、RELOAD 権限 (FLUSH TABLES を実行できるように)、および LOCK TABLES 権限 (テーブルをロックできるよう
MySQL :: MySQL 8.0 リファレンスマニュアル :: 4.8.2 perror — MySQL エラーメッセージ情報の表示
perror に、MySQL またはオペレーティングシステムのエラーコードのエラーメッセージが表示されます。 perror は次のように起動します。 shell> perror [options] errorcode ... perror は、引数を柔軟に理解しようとします。 たとえば、ER_WRONG_VALUE_FOR_VAR エラーの場合、perror はこれらの引数のいずれかを認識: 1231、001231、MY-1231、MY-001231 または ER_WRONG_VALUE_FOR_VAR。 shell> perror 1231 MySQL error code MY-001231 (ER_WRONG_VALUE_FOR_VAR): Variable '%-.64s' can't be set to the value of '%-.200s' エラー番号が、MySQL とオ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.6 マルチカラムインデックス
MySQL は複合インデックス (つまり、複数のカラムに対するインデックス) を作成できます。 インデックスは最大 16 カラムで構成できます。 特定のデータ型では、カラムのプリフィクスにインデックスを設定できます (セクション8.3.5「カラムインデックス」を参照してください)。 MySQL では、インデックスで、すべてのカラムをテストするクエリーまたは最初のカラム、最初の 2 つのカラム、最初の 3 つのカラムというようにテストするクエリーにマルチカラムインデックスを使用できます。 インデックス定義の正しい順序でカラムを指定する場合、単一の複合インデックスにより、同じテーブルへの複数の種類のクエリーを高速化できます。 マルチカラムインデックスは、インデックス設定されたカラムの値を連結して作成された値を格納する行である、ソート済みの配列とみなすことができます。 複合インデックスの代わりに
MySQL :: MySQL 4.1 リファレンスマニュアル :: 6.9.1 クエリキャッシュの動作
クエリは解析前に比較されるため、 SELECT * FROM tbl_name と Select * from tbl_name は、クエリキャッシュで別のクエリとみなされます。完全に一致する（各バイトが）クエリ以外、同一とはみなされません。 また、たとえば、あるクライアントで新しい形式の通信プロトコルを使用している場合や、別のクライアントが使用しているものとは異なるキャラクタセットを使用している場合も、同じものであるはずのクエリが異なるものとして認識されることがあります。 異なるデータベースを使用するクエリや、使用プロトコルのバージョンが異なるクエリ、またデフォルトのキャラクタセットが異なるクエリは、いずれも異なるクエリとして認識され、別々にキャッシュされます。 キャッシュは SELECT SQL_CALC_FOUND_ROWS ... および SELECT FOUND_ROWS() .
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.4.1 バックアップ用にレプリケーションを使用する
MySQL :: MySQL 8.0 Reference Manual :: 5.1.7 Server System Variables