MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.6 マルチカラムインデックス
MySQL は複合インデックス (つまり、複数のカラムに対するインデックス) を作成できます。 インデックスは最大 16 カラムで構成できます。 特定のデータ型では、カラムのプリフィクスにインデックスを設定できます (セクション8.3.5「カラムインデックス」を参照してください)。 MySQL では、インデックスで、すべてのカラムをテストするクエリーまたは最初のカラム、最初の 2 つのカラム、最初の 3 つのカラムというようにテストするクエリーにマルチカラムインデックスを使用できます。 インデックス定義の正しい順序でカラムを指定する場合、単一の複合インデックスにより、同じテーブルへの複数の種類のクエリーを高速化できます。 マルチカラムインデックスは、インデックス設定されたカラムの値を連結して作成された値を格納する行である、ソート済みの配列とみなすことができます。 複合インデックスの代わりに
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.2.9 REPLACE ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.2.1.6 インデックスコンディションプッシュダウンの最適化
インデックスコンディションプッシュダウン (ICP) は、MySQL がインデックスを使用してテーブルから行を取得する場合の最適化です。 ICP を使用しない場合、ストレージエンジンはインデックスをトラバースして、ベーステーブル内で行を検索し、MySQL Server に返し、MySQL Server が行に対して WHERE 条件を評価します。 ICP が有効で、インデックスのカラムのみを使用して WHERE 条件の一部を評価できる場合、MySQL サーバーは WHERE 条件のこの部分をストレージエンジンにプッシュダウンします。 ストレージエンジンは、インデックスエントリを使用して、プッシュされたインデックス条件を評価し、これが満たされている場合にのみ、テーブルから行を読み取ります。 ICP は、ストレージエンジンがベーステーブルにアクセスする必要がある回数と、MySQL サーバーがス
MySQL :: MySQL 8.0: Retiring Support for the Query Cache
As Rene wrote on the ProxySQL blog yesterday: Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck. This is indeed something we have observed in the MySQL team for a while. Before we get to the subject of today’s post, let me start with an introduction. Introduction to Query Cache The MySQL query cache is a quer
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.9.3 DYNAMIC および COMPRESSED 行フォーマット
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
MySQL :: MySQL 8.0 リファレンスマニュアル :: 2.3.4.8 Windows のサービスとして MySQL を起動する
Windows で MySQL を実行する場合、Windows の起動および停止時に MySQL が自動的に起動および停止するように、Windows サービスとしてインストールすることが推奨されています。 MySQL Server をサービスとしてインストールすると、NET コマンドを使用してコマンド行から、あるいはグラフィカル Services ユーティリティーで管理することもできます。 一般に、MySQL を Windows サービスとしてインストールするときは、管理者権限のあるアカウントを使ってログインするようにしてください。 Services ユーティリティ (Windows Service Control Manager) は、Windows コントロールパネルにあります。 競合を避けるために、サーバーのインストールまたはコマンド行からの削除操作の際には、Services ユーテ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.9 B ツリーインデックスとハッシュインデックスの比較
B ツリーおよびハッシュデータ構造を理解することは、インデックスにこれらのデータ構造を使用するさまざまなストレージエンジンで (特に B ツリーインデックスを使用するか、ハッシュインデックスを使用するかを選択できる MEMORY ストレージエンジンの場合に)、さまざまなクエリーがどのように実行されるかを予測するのに役立つ可能性があります。 B ツリーインデックスは =、>、>=、<、<=、または BETWEEN 演算子を使用する式で、カラム比較に使用できます。 このインデックスは、LIKE への引数がワイルドカード文字で始まらない定数文字列の場合の LIKE 比較にも使用できます。 たとえば、次の SELECT ステートメントはインデックスを使用します。 SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%'; SELECT * FROM
MySQL :: MySQL 8.0.1: Japanese collation for utf8mb4
In MySQL 8.0.1, in addition to new as_cs collations (accent sensitive, case sensitive) for utf8mb4, we have also added a new collation for Japanese. Introducing utf8mb4_ja_0900_as_cs Collating rules for for Japanese are complex. Japanese has multiple writing systems with katakana, hiragana, kanji, romaji. On top of that, for a single character, there are fullwidth and halfwidth symbols. For exam
MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.1.8 サーバーシステム変数
MySQL サーバーは、その操作を構成する多くのシステム変数を保持します。 各システム変数にはデフォルト値があります。 システム変数は、コマンド行のオプションを使用するか、オプションファイルでサーバー起動時に設定できます。 これらのほとんどは、実行時に SET ステートメントを使用して動的に変更できます。これにより、サーバーを停止して再起動しなくても、サーバーの操作を変更できます。 式でシステム変数値を使用することもできます。 グローバルシステム変数のランタイム値を設定するには、通常、SYSTEM_VARIABLES_ADMIN 権限 (または非推奨の SUPER 権限) が必要です。 セッションシステムランタイム変数値を設定する場合、通常は特別な権限は必要なく、すべてのユーザーが実行できますが、例外があります。 詳細は、セクション5.1.9.1「システム変数権限」を参照してください シス
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.3 InnoDB のロックモード
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.3.3 暗黙的なコミットを発生させるステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL InnoDB Cluster GA is Available Now!
The MySQL Development Team is happy to announce the first GA release of InnoDB Cluster–our integrated, native, full stack HA solution for MySQL. You can see highlights of the changes and improvements made since the RC release here, and you can download the GA packages from our MySQL APT (Ubuntu, Debian) and YUM (Redhat, OEL, Fedora) repositories or from dev.mysql.com. InnoDB Cluster consists of th
MySQL :: MySQL 5.6 リファレンスマニュアル :: 9.3 予約語
SELECT、DELETE、または BIGINT などの特定の語は、テーブル名やカラム名などの識別子として使用するために予約されており、特別な取り扱いが必要になります。これは、組み込み関数の名前にも当てはまる場合があります。 セクション9.2「スキーマオブジェクト名」で説明しているように、予約語は、引用符で囲まれている場合、識別子として許可されます。 mysql> CREATE TABLE interval (begin INT, end INT); ERROR 1064 (42000): You have an error in your SQL syntax ... near 'interval (begin INT, end INT)' mysql> CREATE TABLE `interval` (begin INT, end INT); Query OK, 0 rows affe
MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.4.5 スロークエリーログ
スロークエリーログは、実行に long_query_time 秒を超える時間がかかり、少なくとも min_examined_row_limit 行を検査する必要がある SQL ステートメントで構成されます。 スロークエリーログは、実行に長い時間がかかっているため最適化の候補となるクエリーを見つけるために使用できます。 ただし、長いスロークエリーログの調査には時間がかかる場合があります。 これを簡単にするために、mysqldumpslow コマンドを使用してスロークエリーログファイルを処理し、その内容を要約できます。 セクション4.6.9「mysqldumpslow — スロークエリーログファイルの要約」を参照してください。 初期ロックを取得する時間は実行時間として計算されません。mysqld がスロークエリーログにステートメントを書き込むのは、ステートメントが実行されて、すべてのロックが解
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.17.2 InnoDB モニターの有効化
トラブルシューティングを支援するために、InnoDB は、特定の状況で InnoDB 標準モニターの出力を一時的に有効にします。 詳細は、セクション15.21「InnoDB のトラブルシューティング」を参照してください。 InnoDB モニターの出力は、タイムスタンプとモニター名を含むヘッダーで始まります。 例: ===================================== 2014-10-16 18:37:29 0x7fc2a95c1700 INNODB MONITOR OUTPUT ===================================== ロックモニターでは、追加のロック情報が付加された同じ出力が生成されるため、InnoDB 標準モニターのヘッダー (INNODB MONITOR OUTPUT) はロックモニターにも使用されます。 innodb_stat
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.2.2 DATE、DATETIME、および TIMESTAMP 型
DATE、DATETIME、および TIMESTAMP 型は関連しています。 このセクションでは、これらの特徴、似ている点、および異なる点について説明します。 MySQL は、セクション9.1.3「日付リテラルと時間リテラル」で説明している複数の形式で、DATE、DATETIME、および TIMESTAMP 値を認識します。 DATE および DATETIME 範囲の説明では、「サポートされている」とは、以前の値は機能するが、保証はないということを意味します。 DATE 型は、日付部分を含むが時間部分は含まない値に使用されます。 MySQL は、DATE 値を'YYYY-MM-DD'形式で取得して表示します。 サポートしている範囲は '1000-01-01' から '9999-12-31' です。 DATETIME 型は、日付と時間の両方の部分を含む値に使用されます。 MySQL は、DA
MySQL 4.1 リファレンスマニュアル :: 6.4.1.1 JOIN 構文
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.9.3 MySQL クエリーキャッシュ
クエリーキャッシュには、クライアントに送信された対応する結果とともに、SELECT ステートメントのテキストが格納されます。あとで同じステートメントを受け取った場合、サーバーはそのステートメントを再度解析して実行する代わりに、クエリーキャッシュから結果を取得します。クエリーキャッシュはセッション間で共有されるため、1 つのクライアントで生成された結果セットを、別のクライアントによって発行された同じクエリーへの応答で送信できます。 クエリーキャッシュは、あまり頻繁に変更されないテーブルがあり、それに対してサーバーが多くの同一のクエリーを受け取る環境で役立つことがあります。これは、データベースの内容に基づいて、多くの動的ページを生成する多くの Web サーバーに一般的な状況です。 クエリーキャッシュは古くなったデータを返しません。テーブルが変更されると、クエリーキャッシュ内の関連エントリがフラ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.8.2 EXPLAIN 出力フォーマット
EXPLAIN ステートメントは、MySQL がステートメントを実行する方法に関する情報を提供します。 EXPLAIN は、SELECT, DELETE, INSERT, REPLACE および UPDATE ステートメントで動作します。 EXPLAIN は SELECT ステートメントで使用される各テーブルに関する情報の行を返します。 これは、MySQL がステートメントの処理中にテーブルを読み取る順番で、出力にテーブルを一覧表示します。 これは、MySQL が最初のテーブルから行を読み取り、次に 2 番目のテーブル、3 番目のテーブルなどで一致する行を検索することを意味します。 すべてのテーブルが処理されると、MySQL は選択したカラムを出力し、さらに一致する行があるテーブルが見つかるまで、テーブルリストを逆戻りします。 次の行がテーブルから読み取られ、プロセスは次のテーブルに進みま
MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.4.3 mysql_install_db — MySQL データディレクトリの初期化
mysql_install_db は MySQL データディレクトリを初期化し、システムテーブルを作成します (システムテーブルがない場合)。また、InnoDB テーブルの管理に必要な、システムのテーブルスペースおよび関係するデータ構造体も初期化します。MySQL 5.6.8 では、mysql_install_db は Perl スクリプトで、Perl がインストールされた任意のシステムで使用できます。5.6.8 より前ではシェルスクリプトで、Unix プラットフォームでのみ使用可能です。 MySQL 5.6.8 以降では、mysql_install_db は UNIX プラットフォーム上で、my.cnf という名前のデフォルトオプションファイルを基本インストールディレクトリに作成します。このファイルは my-default.cnf という名前の配布パッケージに含まれるテンプレートから作成
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
