「ちょっと待て」 真・MySQLのクエリを最適化する10のTips：CodeZine
Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言
捕捉：MT 3.31 + SQLiteがベラボーに遅い件について - Tociyuki::Diary
Ogawa::Memoranda さんが指摘されている、MovableType (以下、MT)の 3.31 ブランチの、mt_entry 表と mt_objecttag 表の結合で、SQLite の最適化が不適切になる理由を調べてみました。 結論を先に述べると、mt_entry.entry_status へのインデックスが存在するために、SQLite の最適化ルーチンがだまされていました。SQLite ではインデックスが存在すると、行のふるい落しがおこなわれることを暗に期待するのですが、残念ながら、通常のブログにおいては mt_entry.entry_status = 2 の制約条件は、行のふるい落しに寄与せず、mt_entry のほとんどの行を参照していました。 さて、問題は次のような単純な結合をもつ SELECT 文です(注： mt_entry 表と mt_objecttag 表には同
SQL Cookbook
Why I Wrote This BookObjectives of This BookAudience for This BookHow to Use This BookWhat’s Missing from This BookStructure of This BookPlatform and VersionTables Used in This BookConventions Used in This BookUsing Code ExamplesComments and QuestionsSafari® EnabledAcknowledgments 1.1. Retrieving All Rows and Columns from a Table1.2. Retrieving a Subset of Rows from a Table1.3. Finding Rows That S
Class::DBI::SweetでのJOIN : blog.nomadscafe.jp
Class::DBI::SweetでのJOIN Class::DBI::Sweetのjoinをつかった検索を試してみた。 ソースコードは作っているアプリケーションからの抜きだしなので足りないところがあるかも。 EntryとそのTagを想定して、 package Entries; __PACKAGE__->table('entries'); __PACKAGE__->columns(All=>qw/id title text created_on/); __PACKAGE__->has_many("tags"=>'Tags'); 1; package Tags; __PACKAGE__->table('tags'); __PACKAGE__->columns(All=>qw/id entry_id tag/); __PACKAGE__->has_a('entry_id'=>'Entries'
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
