要するに、データベースにnullが1つでも含まれていれば、クエリから正しくない結果が返される可能性がある。しかも、一般的には、どのクエリから正しくない結果が返されるのかを知る方法はないので、すべての結果があやしく見えてくる。nullが含まれたデータベースから正しい結果が得られることは確信できない。筆者に言わせれば、この状況はまさにお手上げである。 ――――C.J.デイト はじめに 多くのプログラミング言語が、真理値型（BOOL型、BOOLEAN型）というデータ型を持っています。もちろん、SQLにも真理値型が存在します。ユーザーが直接扱えるデータ型として定義されたのはSQL-99ですが、WHERE句などの条件の評価時にも真理値の演算が行なわれています。 ところで、普通のプログラミング言語の真理値型とSQLの真理値型の違いをご存知でしょうか？ それは、普通の言語の真理値型が、true、fals
CSVファイルからOracleのテーブルへデータを流し込むツール。 大量のinsert文を発行するよりは、断然高速。 データであるCSVファイルや固定長ファイルと、ロード方法を指定するコントロールファイルを用意 して実行する。 （CSVファイルからのロードはこのSQL*Loaderが使えるが、CSV出力には標準的な方法は無いらしくて、select文で加工する方法がよく使われるらしい。 このSQL文をいちいち書くのは少々面倒なので、SQL生成用Excelマクロを作ってみました） コントロールファイル CSVファイルの各項目とテーブルの項目との関連付け等を指定する。 （コントロールファイルをテキストエディタで書くのはけっこう面倒なので、コントロールファイル作成用Excelマクロを作ってみました（CSVファイル用、固定長ファイル用）） 例）emp.ctl： OPTIONS(LOAD=100,SK
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
MySQL に限らず、SQL のNULL の仕様には何回か「えっ」と驚くことがあったのでメモしておこうと思います。5.1 版の日本語マニュアルがなかったものについては、4.1 のマニュアルを参照しました。 そもそもNULL は何を意味するか NULL は未定義または、不明を意味する。「電話番号を持たない」ということを表現する場合は、NULL ではなく、空の文字列を使う。 NULL 値というものを SQL 初心者はよく混乱します。SQL 初心者は、多くの場合、NULL が空文字 "" と同じであると考えてしまいます。これは違います。たとえば、以下のステートメントは完全に別のものです。 mysql> INSERT INTO my_table (phone) VALUES (NULL); mysql> INSERT INTO my_table (phone) VALUES (""); どちらのス
Open database life
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
文字コードの多様化とインターネットやクライアント-サーバーなどの分散環境の普及によって，文字化けトラブルの頻度が飛躍的に拡大した。特に Webシステムでは，WebブラウザとWebサーバー，プログラム(スクリプト)言語，そしてデータベースと文字化けが発生する要因が数多く存在する。 Webサーバー側の文字化けは，他のコラムにお任せすることとして，今回はMySQLの文字化けに関して解説する。 文字化けの仕組み 文字化けは開発者にとって悩みの種である。しかし，文字化けの仕組みを少しでも知っていれば，意外と簡単に解決できるものだ。このコラムで，ぜひその知識を学んでほしい。 MySQL 4.1の変更点 さて，MySQLにおいては，バージョン4.1のリリースを境に文字化けが起きることが非常に多くなった。では，バージョン4.1は，それ以前のバージョンと何が変わったのだろうか。そこに文字化けを解決するヒント
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
前回は形態素解析を使う検索エンジンのしくみについて説明しました。今回は、FINDSPOTで使用しているN-gramという検索エンジンのしくみについて説明します。 N-gramによる見出し語の切り出し 前回は、形態素解析による検索エンジンでは、検索可能な最小単位が分かち書きの切り分け単位となる点を説明しました。 一方、N-gramを使った検索エンジンでは、単純に文字の並びを見出し語としてインデックスを作成します。1文字を元にインデックスを作成する方法をユニグラム、2文字の並びを元にインデックスを作成する方法をバイグラム、3文字の並びを元にインデックスを作成する方法をトリグラムと呼んでいます。 1文字：ユニグラム 2文字：バイグラム 3文字：トリグラム N-gramによる見出し語の切り出しは、形態素解析のための文法解析を伴わないため、特定の自然言語に依存しないという特徴があります。 FINDS
某DBにて、いろいろ試行錯誤しながら、日本語による全文検索を実装することができた。 はたして本当に効果があったのだろうか・・・と調べてみる。 全レコード数：32740 フィールド(フィールドタイプ：TEXT)には、日本語による文章を入れてあり、 全体のうち、4つのレコードのに世界最大のカルデラを持った阿蘇５岳の一つ、山頂のギザギザが特徴的な根子岳です。（省略）という文章が入っている。で、全レコードから「ギザギザ」という文字で検索するとする。この４レコードを探すとする。 LIKEでやる場合、 SELECT * FROM `main` WHERE COMMENT LIKE "%ギザギザ%" レコード表示 0 - 3 (4 合計, Query took 3.1908 sec) と、3秒ちょっとかかった。（実はサーバ自体の性能もあまりよくないんだけれど） EXPLAINすると、ro
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
RDBMSを使ってシステムを構築するには，RDBMSにアクセスするための専用言語「SQL」を習得する必要がある。SQLは，C/C++やJava などと同じようなプログラミング言語と考えて扱うと失敗しやすい。 汎用のプログラミング言語の多くは「手続き型」と呼ばれ，処理手順をプログラミングする言語である。一方のSQLは「非手続き型」と呼ばれる言語で，処理手順はプログラミングしない。こうした違いを中心に，SQLを使い始める際に陥りやすい失敗や気をつけるべき点などを解説する。 ・第1回（前半） 条件句の注意点 ・第1回（後半） 演算の優先順位，ソートの注意点 ・第2回（前半） 文字列型の注意点(1) ・第2回（後半） NULL値，複合インデックスの注意点 ・第3回（前半） 日付型の注意点 ・第3回（後半） 集約関数，GROUP BY句，HAVING句の注意点 ・第4回 副問い合わせ，ビューの注意点
この章では、MySQL のパフォーマンスを最適化する方法について説明し、例を示します。 最適化には、いくつかのレベルでの構成、チューニング、およびパフォーマンスの測定が含まれます。 業務の役割 (開発者、データベース管理者、または両方の組み合わせ) に応じて、個々の SQL ステートメント、アプリケーション全体、単一のデータベースサーバー、または複数のネットワーク接続されたデータベースサーバーのレベルで最適化できます。 プロアクティブにパフォーマンスを事前に計画する場合や、または問題の発生後に、構成やコードの問題のトラブルシューティングを行う場合があります。 CPU やメモリーの使用を最適化することで、スケーラビリティーを向上し、データベースを低下させず、より多くの負荷を処理させることもできます。
ここまでは単一の列に対して作成するインデックスを前提にお話ししてきました。しかし、インデックスは同一テーブルの複数の列に対してまとめて設定することもできます。検索条件に複数列を指定する場合などは、このようなインデックスを使えばさらに効率よく処理を行うことができます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
