正確な最大長がわからないときの最小かつ十分なサイズの値ってどう決めるのが良いのだろうーと思ってつぶやいてみたところ、多くの方々に返信いただけました。ありがとうございます。
MySQLのVARCHARサイズについて
正確な最大長がわからないときの最小かつ十分なサイズの値ってどう決めるのが良いのだろうーと思ってつぶやいてみたところ、多くの方々に返信いただけました。ありがとうございます。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.6.5.2 構成可能な InnoDB の自動インクリメントロック
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
Query_time - Lock_time > long_query_time - takatoshiono's blog
MySQL(InnoDB)でロック待ちタイムアウトになるクエリはスロークエリログに記録されるのか？ 気になったので調べていた。 ロック待ちタイムアウト あるトランザクションで UPDATE 中の行を他のトランザクションから UPDATE しようとするとロック待ちになる ロック待ちの時間が innodb_lock_wait_timeout に設定された秒数を超えると Lock wait timeout exceeded; try restarting transaction というエラーが発生する スロークエリログ (MySQl 5.0) さて、このときスロークエリログは？ # Query_time: 51 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 SET timestamp=1423478293; update ... こういう記録が残っていた。
MySQLパフォーマンスチューニングのためのクエリの基礎知識 - プログラマーkkの勉強/成長ブログ@ライブレボリューション(モバイル広告代理店)
前回書いたMySQLパフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
MySQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断 | Yakst
MySQLのインデックスを効果的に使う方法の第2弾。よく似た2つのクエリなのに、実際にはインデックスの使い方がそれぞれ異なることを通じて、オプティマイザがどのようにクエリの実行計画を立案するのか、そしてその結果どうインデックスが使われるのかを解説する。 前の記事では、ひとつのテーブルに対する様々なクエリを対象にして、インデックスのデザイン方法について議論しました。この記事ではより実世界に即した問題解決の例として、よく似ているにも関わらず、ひとつは適したインデックスを使い、もうひとつはフルテーブルスキャンをしてしまうという、2つのクエリを取り上げます。動作の違いはバグなのでしょうか？それとも想定された動きなのでしょうか？続きを読んでみてください！ 対象のクエリ2つ # Q1 mysql> explain select col1, col2 from t where ts >= '2015-0
MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる
tl;dr: MySQL 5.5.14以降だとinnodb_large_prefixオプションで3072バイトまでインデックス張れる MySQL(InnoDB)では、ひとつのカラムのキープレフィックスの最大値が767バイトという制限があるので、ついうっかりして Index column size too large. The maximum column size is 767 bytes. とか Specified key was too long; max key length is 767 bytes といったエラーを見たことある人は多いのではないかと思います。 よくあるケースだと、varchar(256)以上のutf8なカラムにインデックスを張ろうとするとこのエラーとご対面できます。 CREATE TABLE t (c varchar(256), index (c)); ERROR
キーの最大長と文字エンコーディング設定 - HHeLiBeXの日記 正道編
今までsjisとかujisとかだったMySQLのデータベースをutf8mb4に変換しようとしていたときの話。キーの最大長という壁にぶつかったらしい。 http://d.hatena.ne.jp/takihiro/20080306/1219295452 MySQLのリファレンスを見ると、こんなことが書いてある。 プレフィックスは、最大1000バイト長(InnoDBテーブルに対しては767バイト)まで可能です。プレフィックスの最大長はバイトで評価されます。一方、CREATE TABLEステートメント内のプレフィックス長は文字数として解釈されます。プレフィックス長を、マルチバイトキャラクタセットを使用するカラムに対して指定するときこのことを考慮に入れなければいけません。 ここでは、直接的にはTEXT型やBLOB型について言っているのだが、VARCHAR型なども同様。 ということで、以下のようなC
MongoDB Indexing: The Details
1. MongoDBIndexing and Query Optimizer DetailsAaron StapleMongoSVDecember 3, 2010 2. What will we cover?Many details of how indexing and the query optimizer workA full understanding of these details is not required to use mongo, but this knowledge can be helpful when making optimizations.We’ll discuss functionality of Mongo 1.8 (for our purposes pretty similar to 1.6 and almost identical to 1.7 ed
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.13 InnoDB テーブルおよびインデックスの構造
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
MySQLでインデックスを使って高速化するならCovering Indexが使えそう - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
InnoDBテーブルでインデックスを拡張するとパフォーマンスが落ちるかも from MySQL Performance Blog - stnard.jp
Extending Index for Innodb tables can hurt performance in a surprising way 多くのキーを使うクエリーのときに、よく最適化するときにインデックスを拡張する。通常は問題なく、インデックスの長さが劇的に増加しない限り、インデックスを使うクエリーは新しいインデックスの先頭を使うことができる。では、そうではない場合を見てみよう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE `idxitest` ( `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `a` int(11) NOT NULL, `b` int(11) NOT NULL, PRIMARY KEY (`id`),
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL(InnoDB) で charset を utf8mb4 にする注意点の現在
MySQLにおけるJOINのチューニングの定石
MySQLチューニング虎の巻一覧