LOAD DATA INFILE時の文字コード - メモ帳
問題 latin1のデータをselect into outfileでエクスポート/ダンプして、load data infileでインポートすると、警告がでてうまくいかない。 mysql> use world; Database changed mysql> show tables; +-----------------+ | Tables_in_world | +-----------------+ | city | | country | | countrylanguage | +-----------------+ 3 rows in set (0.13 sec) mysql> select * into outfile 'c:\cl.txt' from countrylanguage; Query OK, 984 rows affected (0.19 sec) mysql> cre
SQL*Loaderメモ(Hishidama's sqlloader for Oracle9i Memo)
CSVファイルからOracleのテーブルへデータを流し込むツール。 大量のinsert文を発行するよりは、断然高速。 データであるCSVファイルや固定長ファイルと、ロード方法を指定するコントロールファイルを用意 して実行する。 （CSVファイルからのロードはこのSQL*Loaderが使えるが、CSV出力には標準的な方法は無いらしくて、select文で加工する方法がよく使われるらしい。 このSQL文をいちいち書くのは少々面倒なので、SQL生成用Excelマクロを作ってみました） コントロールファイル CSVファイルの各項目とテーブルの項目との関連付け等を指定する。 （コントロールファイルをテキストエディタで書くのはけっこう面倒なので、コントロールファイル作成用Excelマクロを作ってみました（CSVファイル用、固定長ファイル用）） 例）emp.ctl： OPTIONS(LOAD=100,SK
TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
スケーラブルなデータベースを実現する手段として「Sharding MySQL plus memcached」がよく知られる方法だとは、1つ前の記事「MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論」で紹介しました。 ちなみに「Sharding」（シャーディング）とは複数のデータベースにデータを分散して運用することで、ざっくりいえばShared Nothing的な分散データベース構成のことです（この記事で紹介する英文中には「Shared MySQL」（共有MySQL）との記述がありますが、これは恐らく「Sharded MySQL」（ShardされたMySQL）のミススペルではないと推測します）。 日本で（たぶん）もっともMySQLについて詳しく解説してあるブログ「漢(オトコ)のコンピュータ道」のエントリ「さらにMySQLを高速化する7つの方法」では、Sh
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 でのインデックス
MySQL のNULL ではまったことあれこれ - LukeSilvia’s diary
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 (""); どちらのス
これだけは覚えておきたい!!MySQL の６つの自動変換 - sakaikの日々雑感～(T)編
MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する６つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 １．[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ（unsignedの場合は43億弱）。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
［MySQLウォッチ］第36回 文字化けのメカニズム
文字コードの多様化とインターネットやクライアント-サーバーなどの分散環境の普及によって，文字化けトラブルの頻度が飛躍的に拡大した。特に Webシステムでは，WebブラウザとWebサーバー，プログラム(スクリプト)言語，そしてデータベースと文字化けが発生する要因が数多く存在する。 Webサーバー側の文字化けは，他のコラムにお任せすることとして，今回はMySQLの文字化けに関して解説する。 文字化けの仕組み 文字化けは開発者にとって悩みの種である。しかし，文字化けの仕組みを少しでも知っていれば，意外と簡単に解決できるものだ。このコラムで，ぜひその知識を学んでほしい。 MySQL 4.1の変更点 さて，MySQLにおいては，バージョン4.1のリリースを境に文字化けが起きることが非常に多くなった。では，バージョン4.1は，それ以前のバージョンと何が変わったのだろうか。そこに文字化けを解決するヒント
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.10 全文検索関数
MATCH (col1,col2,...) AGAINST (expr [search_modifier]) search_modifier: { IN NATURAL LANGUAGE MODE | IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION | IN BOOLEAN MODE | WITH QUERY EXPANSION } MySQL では、次のような全文インデックス設定および検索がサポートされています。 MySQL の全文インデックスは、型 FULLTEXT のインデックスです。 全文インデックスは、InnoDB または MyISAM テーブルでのみ使用でき、CHAR、VARCHAR、または TEXT カラムにのみ作成できます。 MySQL には、中国語、日本語および韓国語 (CJK) をサポートする組込みの全文 ngram パーサー
VB SQL テーブルの結合 - LEFT JOIN, RIGHT JOIN, INNER JOIN, FULL OUTER JOIN, CROSS JOIN, UNION
Visual Basic 中学校 > データベース講座 > 第10回 テーブルの結合 SQLの中で、複数のテーブルを結合してあたかも１つのテーブルであるかのように扱う基本的な手法を説明します。 概要 ・JOINを使用すると複数のテーブルを結合して、１つのテーブルであるかのように扱うことができる。結合はレコード単位で行われ、どのレコードとどのレコードを結合させるかはSQL文中で指定する。 例：以下の例ではT_動物マスタとT_目マスタで、目IDが等しいレコード同士を結合して、あたかも１つのテーブルであるかのようにFROM句に指定する。 SELECT T_動物マスタ.名前, T_目マスタ.目名 FROM T_動物マスタ LEFT JOIN T_目マスタ ON T_動物マスタ.目ID = T_目マスタ.目ID ・JOINにはいくつかの種類があり、結合相手のレコードがいない場合の結果が変わる
JOINの条件式にCase文を入れる - ぶろぐらまぁの日記
例）テーブルBの品番が「999」のときは「333」に置き換えて結合、それ以外はそのまま結合 select * from テーブルA as a left join テーブルB as b on a.品番 = (case when b.品番 = '999' then '333' else b.品番 end) where a.xxx = xxx
BKCon 2006 - にぽたん研究所
昨日は 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 の時と大凡同じでしたが、プレゼンの持ち
第5回 N-gramのしくみ | gihyo.jp
前回は形態素解析を使う検索エンジンのしくみについて説明しました。今回は、FINDSPOTで使用しているN-gramという検索エンジンのしくみについて説明します。 N-gramによる見出し語の切り出し 前回は、形態素解析による検索エンジンでは、検索可能な最小単位が分かち書きの切り分け単位となる点を説明しました。 一方、N-gramを使った検索エンジンでは、単純に文字の並びを見出し語としてインデックスを作成します。1文字を元にインデックスを作成する方法をユニグラム、2文字の並びを元にインデックスを作成する方法をバイグラム、3文字の並びを元にインデックスを作成する方法をトリグラムと呼んでいます。 1文字：ユニグラム 2文字：バイグラム 3文字：トリグラム N-gramによる見出し語の切り出しは、形態素解析のための文法解析を伴わないため、特定の自然言語に依存しないという特徴があります。 FINDS
mysqlで日本語全文検索の効果 (Nega Diary)
某DBにて、いろいろ試行錯誤しながら、日本語による全文検索を実装することができた。 はたして本当に効果があったのだろうか・・・と調べてみる。 全レコード数：32740 フィールド(フィールドタイプ：TEXT)には、日本語による文章を入れてあり、 全体のうち、4つのレコードのに世界最大のカルデラを持った阿蘇５岳の一つ、山頂のギザギザが特徴的な根子岳です。（省略）という文章が入っている。で、全レコードから「ギザギザ」という文字で検索するとする。この４レコードを探すとする。 LIKEでやる場合、 SELECT * FROM `main` WHERE COMMENT LIKE "%ギザギザ%" レコード表示 0 - 3 (4 合計, Query took 3.1908 sec) と、3秒ちょっとかかった。（実はサーバ自体の性能もあまりよくないんだけれど） EXPLAINすると、ro
MySQLの最適化
限りなく眠気を誘う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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.orange-times.net/nucleusutf8.html
SQLで木と階層構造のデータを扱う――入れ子集合モデル
Mikio Hirabayashi（平林幹雄）
MSDN ホームページ
