サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
dev.mysql.com
InnoDB の FULLTEXT インデックスでは、転置インデックスの設計が使用されています。 転置インデックスには、単語のリスト、および単語ごとに、その単語が出現するドキュメントのリストが格納されます。 近接検索をサポートするために、単語ごとの位置情報もバイトオフセットとして格納されます。 InnoDB FULLTEXT インデックスを作成すると、次の例に示すように、インデックステーブルのセットが作成されます: mysql> CREATE TABLE opening_lines ( id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, opening_line TEXT(500), author VARCHAR(200), title VARCHAR(200), FULLTEXT idx (opening_line) ) ENGINE
Contention-Aware Transaction Scheduling Arriving in InnoDB to Boost Performance Authors: Sunny Bains, Jiamin Huang (University of Michigan) What is Transaction Scheduling? Locking is one of the most popular mechanisms for concurrency control in most database systems, including Oracle MySQL. One major question, however, seems to have been overlooked by all database vendors: Q: When multiple transac
The long awaited first release candidate of MySQL 8.0 is now available. The theme of this release is “making MySQL better for modern apps”. What does that mean exactly? A modern application is mobile first. Mobile-first is not just a theme applied to an existing app, it is about using context about the user (such as their location) and reducing the clicks required for a transaction. Unicode (or mo
Overview The MySQL protocol is used between MySQL Clients and a MySQL Server. It is implemented by: Connectors (Connector/C, Connector/J, and so forth) MySQL Proxy Communication between master and slave replication servers The protocol supports these features: Transparent encryption using SSL Transparent compression A Connection Phase where capabilities and authentication data are exchanged A Comm
IN、= ANY または EXISTS 述語で使用されるサブクエリーの場合、オプティマイザには次の選択肢があります:
GROUP BY 句を満たすもっとも一般的な方法は、テーブル全体をスキャンし、各グループのすべての行が連続する新しい一時テーブルを作成することであり、それにより、この一時テーブルを使用してグループを見つけて、集約関数 (ある場合) を適用できます。 場合によっては、MySQL はそれよりはるかに優れた処理を実行でき、インデックスアクセスを使用した一時テーブルの作成を回避できます。 GROUP BY のインデックスを使用するための最も重要な前提条件は、すべての GROUP BY カラムが同じインデックスの属性を参照し、インデックスにそのキーが順番に格納されることです (たとえば、BTREE インデックスの場合は該当しますが、HASH インデックスの場合は該当しません)。 一時テーブルの使用をインデックスアクセスに置き換えられるかどうかは、クエリー内でインデックスのどの部分が使用されているか、
The MySQL Development team is happy to announce our 8.0.2 development milestone release (DMR), now available for download at dev.mysql.com. (8.0.2 adds features to 8.0.1 and 8.0.0). The source code is available at GitHub. You can find the full list of changes and bug fixes in the 8.0.2 Release Notes. Here are the highlights. Enjoy! SQL Window Functions Add first batch of SQL window functions (WL#9
以前の記事では、MySQL 8.0.1で導入された新しい 日本語のutf8bm4のCollation(文字照合順)について ご紹介しました。このcollation (utf8mb4_ja_0900_as_cs) は、CLDR 30で定義されたアクセント記号(清音濁音半濁音)ならびに大文字小文字(拗音促音など)を判別する実装となっています。 今日ご紹介するのはひらがなカタカナを判別できる新しい「かなセンシティブ」なCollation utf8mb4_ja_0900_as_cs_ksです。DUCETではひらがながカタカナよりも前にソートされるように3次レベルの重みを定義しています。例えば: 3042 ; [.3D5A.0020.000E] # HIRAGANA LETTER A 30A2 ; [.3D5A.0020.0011] # KATAKANA LETTER A 2次レベルでの違い(000
Optimizing Subqueries, Derived Tables, View References, and Common Table Expressions
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 にはテーブル当たり 4096 カラムの強い制限がありますが、特定のテーブルの有効な最大値が少なくなる可能性があります。 カラムの正確な制限は、いくつかの要因によって異なります: すべてのカラムの合計長がこのサイズを超えることはできないため、テーブルの最大行サイズによってカラムの数 (および場合によってはサイズ) が制限されます。 行サイズ制限を参照してください。 個々のカラムの記憶域要件によって、指定された最大行サイズ内に収まるカラム数が制限されます。 一部のデータ型の記憶域要件は、記憶域エンジン、記憶域形式、文字セットなどの要因によって異なります。 セクション11.7「データ型のストレージ要件」を参照してください。 ストレージエンジンは、テーブルカラム数を制限する追加の制限を課す場合があります。 たとえば、InnoDB には、テーブル当たり 1017 カラムの制限があります。
MySQL 8.0.1 introduces two new features which allow you to better manage situations where you have tables with hot row contention. This issue frequently presents itself in scenarios such as worker threads all accessing the same tables trying to find new work, and ecommerce websites trying to keep accurate inventory counts. My example for today will be trying to book tickets to a Hockey game. The
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
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
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
たとえば、DECIMAL(18,9) カラムは小数点の両側に 9 桁あるため、整数部と小数部のそれぞれに 4 バイトが必要です。 DECIMAL(20,6) カラムは整数部に 14 桁、小数部に 6 桁あります。 整数部の桁は、そのうちの 9 桁に 4 バイト、残りの 5 桁に 3 バイトが必要です。 小数部の 6 桁には 3 バイトが必要です。 DECIMAL カラムには、先頭の + 文字、- 文字または先頭の 0 桁は格納されません。 DECIMAL(5,1) カラムに +0003.1 を挿入すると、それは 3.1 として格納されます。 負の数の場合、リテラルの - 文字は格納されません。 DECIMAL カラムでは、カラム定義で暗黙的に指定された範囲を超える値は許可されません。 たとえば、DECIMAL(3,0) カラムは -999 から 999 までの範囲をサポートします。 DEC
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 In MySQL 8.0 our plan is to drastically improve support for utf8. While utf8 support itself dates back to MySQL 4.1, there exist some limitations. The “sushi = beer” problem in the title refers to Bug #76553. Sushi and beer don’t even go well together, at least not to my taste:-) I will use this bug as an example to explain issues with u
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
For legal information, see the Legal Notices. For help with using MySQL, please visit the MySQL Forums, where you can discuss your issues with other MySQL users. Document generated on: 2024-03-20 (revision: 78127)
バッファプールは、InnoDB がアクセス時にテーブルおよびインデックスデータをキャッシュするメインメモリー内の領域です。 バッファープールを使用すると、頻繁に使用されるデータをメモリーから直接処理できるため、処理速度が向上します。 専用サーバーでは、多くの場合、最大 80% の物理メモリーがバッファプールに割り当てられます。 大容量読み取り操作の効率を高めるため、バッファープールは複数行を保持できるページに分割されます。 キャッシュ管理を効率化するために、バッファプールはページのリンクリストとして実装されます。使用頻度が低いデータは、LRU アルゴリズムのバリエーションを使用してキャッシュから削除されます。 バッファプールを利用して頻繁にアクセスされるデータをメモリーに保持する方法を理解することは、MySQL チューニングの重要な側面です。 バッファプールは、最低使用頻度 (LRU) ア
The MySQL Development team is happy to announce our 8.0.0 development milestone release (DMR), now available for download at dev.mysql.com. The source code is available at GitHub. You can find the full list of changes and bug fixes in the 8.0.0 Release Notes. Here are the highlights. Enjoy! Transactional Data Dictionary MySQL 8.0 will have a real Data Dictionary implemented as a set of SQL table
Option Defaults, Options Expecting Values, and the = Sign
Configuration properties define how Connector/J will make a connection to a MySQL server. Unless otherwise noted, properties can be set for a DataSource object or for a Connection object. Configuration properties can be set in one of the following ways: Using the set*() methods on MySQL implementations of java.sql.DataSource (which is the preferred method when using implementations of java.sql.Dat
インデックスコンディションプッシュダウン (ICP) は、MySQL がインデックスを使用してテーブルから行を取得する場合の最適化です。 ICP を使用しない場合、ストレージエンジンはインデックスをトラバースして、ベーステーブル内で行を検索し、MySQL Server に返し、MySQL Server が行に対して WHERE 条件を評価します。 ICP が有効で、インデックスのカラムのみを使用して WHERE 条件の一部を評価できる場合、MySQL サーバーは WHERE 条件のこの部分をストレージエンジンにプッシュダウンします。 ストレージエンジンは、インデックスエントリを使用して、プッシュされたインデックス条件を評価し、これが満たされている場合にのみ、テーブルから行を読み取ります。 ICP は、ストレージエンジンがベーステーブルにアクセスする必要がある回数と、MySQL サーバーがス
ハードウェアまたはオペレーティングシステムのアーキテクチャーによっては、デフォルト (通常は 4K バイト) よりも大きいメモリーページをサポートしています。 このサポートの実際の実装は、ベースとなるハードウェアやオペレーティングシステムに依存します。 大量のメモリーアクセスがあるアプリケーションの場合、大きいページを使用して、トランスレーションルックアサイドバッファー (TLB; Translation Lookaside Buffer) のミスが減ることによってパフォーマンスが改善される可能性があります。 MySQL では、InnoDB でラージページを使用して、バッファープールと追加のメモリープールにメモリーを割り当てることができます。 MySQL での標準的な大規模ページの使用では、サポートされる最大サイズである 4M バイトまでの使用が試行されます。 Solaris では「超大規
EXPLAIN ステートメントは、MySQL がステートメントを実行する方法に関する情報を提供します。 EXPLAIN は、SELECT, DELETE, INSERT, REPLACE および UPDATE ステートメントで動作します。 EXPLAIN は SELECT ステートメントで使用される各テーブルに関する情報の行を返します。 これは、MySQL がステートメントの処理中にテーブルを読み取る順番で、出力にテーブルを一覧表示します。 これは、MySQL が最初のテーブルから行を読み取り、次に 2 番目のテーブル、3 番目のテーブルなどで一致する行を検索することを意味します。 すべてのテーブルが処理されると、MySQL は選択したカラムを出力し、さらに一致する行があるテーブルが見つかるまで、テーブルリストを逆戻りします。 次の行がテーブルから読み取られ、プロセスは次のテーブルに進みま
B ツリーおよびハッシュデータ構造を理解することは、インデックスにこれらのデータ構造を使用するさまざまなストレージエンジンで (特に B ツリーインデックスを使用するか、ハッシュインデックスを使用するかを選択できる MEMORY ストレージエンジンの場合に)、さまざまなクエリーがどのように実行されるかを予測するのに役立つ可能性があります。 B ツリーインデックスは =、>、>=、<、<=、または BETWEEN 演算子を使用する式で、カラム比較に使用できます。 このインデックスは、LIKE への引数がワイルドカード文字で始まらない定数文字列の場合の LIKE 比較にも使用できます。 たとえば、次の SELECT ステートメントはインデックスを使用します。 SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%'; SELECT * FROM
すべての InnoDB テーブルは、行のデータが格納されているクラスタ化されたインデックスと呼ばれる特別なインデックスを持っています。 一般に、クラスタ化されたインデックスは主キーのシノニムです。 クエリー、挿入およびその他のデータベース操作から最高のパフォーマンスを得るには、InnoDB がクラスタインデックスを使用して各テーブルの最も一般的な参照および DML 操作を最適化する方法を理解する必要があります。 テーブル上で PRIMARY KEY を定義すると、InnoDB ではそれがクラスタ化されたインデックスとして使用されます。 作成するテーブルごとに主キーを定義します。 論理的に一意で、Null 以外のカラムまたはカラムのセットが存在しない場合は、自動的に値が入力される新しい自動インクリメントカラムを追加します。 テーブルに PRIMARY KEY が定義されていない場合、MySQ
次のページ
このページを最初にブックマークしてみませんか?
『MySQL :: Developer Zone』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く