MySQLが文字列と数値の比較の際に自動的に変換してしまう件
WHERE句などでint型とchar型を比較すると、 どうやら暗黙的に型変換しちゃう罠があるみたいです。 PHPもそうですが、文字列と数値の比較では、 暗黙的に数値型に変換したうえで比較を行うようです。 例えばproductsテーブルがあったとして、 product_idが主キーでint型だったとします。 そのテーブルに、IDが10番のデータが登録されているとします 残念なことに以下のWHERE句の判定はtrueになってしまいます。 SELECT * FROM products WHERE product_id = '10 a' char型の「10 a」がint型の「10」に暗黙的に型変換されるからです。 ということでちゃんと比較するにはキャストをして型を合わせます。 SELECT * FROM products WHERE CAST(product_id AS CHAR) = '10 a
MySQL で NULL を一番最後にして昇順にソートする | Sun Limited Mt.
2008.2.27 追記 コメントで教えていただきました下記方法で簡単にできました。 is null asc の指定と 通常の asc の指定をするのがポイントですね。 SELECT id, comment FROM table ORDER BY comment IS NULL ASC, comment ASC; —–追記ここまで—– MySQL で昇順にソートすると NULL は一番最初に来ます。 それを最後にできないかということで下記のようなSQL を考えてみました。 SELECT id, comment, CASE WHEN comment IS NULL THEN 10000 ELSE ASCII(LEFT(comment,1)) END AS dummy FROM table ORDER BY dummy ASC, COMMENT ASC comment カラムを昇順でソートして
MySQLのインデックス - Archiva
Make a note of it: Web tech, montaineering, and so on. 『実践ハイパフォーマンスMySQL』4章のまとめ。中から7点をピックアップ。 複合インデックス インデックスによらないソート インデックスによる制約条件 フルテキストインデックス ワイルドカードは重い 非常に多数の行に一致する場合 インデックス情報の表示 読んだのは4章と5章。他はサーバ設定とかデータ分散とか、環境構築に近いディープな話。SQLレベルだとこの辺で十分でしょ。長いので、5章のまとめはまた後で。 マルチカラムインデックス ところで、単に2つのインデックスを作成したのでは、だめなのだろうか。そうしてもかまわないが、MySQLは、両方のインデックスを同時に使用することはできない。この事実は、繰り返し述べるに値するほど重要である。「MySQLでは、1つのクエリを実行するとき、
mysql 日本語＆utf-8ではutf8-general-ciにしましょう - 毎日漫然な愚者
久しぶりの技術メモ MySQLでutf8を指定するときに、 （たぶん）一般的には以下の２つのうちいずれかを用いると思います。 ・utf8-general-ci（デフォルト） ・utf8-unicode-ci で、今回のメモで残したいことは、 このとき、日本語を使うなら必ず ・utf8-general-ci を使いましょうってこと。 なんで、こんなメモを残すかというと、 それぞれのキャラクタセットの違いは、 ・utf8-general-ci：比較条件の拡張なし ・utf8-unicode-ci：比較条件の拡張あり のみなんで、MySQLの公式では、 utf8-unicode-ciを使いましょうみたいなことが書いてありますので、 「じゃぁ・・・」、ということで、 ローカルの環境（windows）でutf8-unicode-ciを設定したら、 ひらがなの「ほ」で条件を指定したのに、 「ぼ」や「ボ
更新があるシステムにはInnoDBを選ぼう。MyISAMを選択するならそれなりの理由が必要。それにInnoDBのパフォーマンスはそんなに悪くないよ。 | 株式会社ビーグッド・テクノロジー／システム�
基本はＩｎｎｏＤＢです。 MyISAMを選択できるようなケースを考えてみます。 ・完全に検索Onlyの場合（基幹系とかから一定間隔で検索用テーブルを再構築する。それ以外の時間は検索のみのようなケース。） ・ログ系のテーブルを出力のみする場合（insertは3～15倍程度MyISAMが高速） 正直、これくらいなのかなと思います。 パフォーマンスについては（5.0.37以上を選択すれば）InnoDBはMyISAMと比べてほとんど同じです。 以下は計測結果です。 InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex InnoDB vs MyISAM パフォーマンス比較 取得件数が多い場合 InnoDB vs MyISAM パフォーマンス比較 SELECT ・・・ LIMIT N InnoDB vs MyISAM
PDO、PEAR::DB、MySQL関数の速度比較
サーバー側の問題もあるので、毎回安定した処理結果は得られませんでしたが、大体上表のような結果になりました。 やはりネイティブ関数は速く、mysqli関数が一番速い結果になりました。 続いて同じくネイティブ関数のmysql関数が続き、その次にPDOという結果になりました。 PDOでは、プリペアドステートメントを用いてSQLを発行したため、2回目のSQLの発行ではキャッシュが効き、劇的な速さになっています。 一番遅かったのは予想通り、PEAR::DBでした。 ネイティブ関数よりも2〜3倍遅く、PDOよりも2倍近く遅い結果となりました。 PHP用アクセラレータを導入していなければ、PEAR::DBはもっと遅くなっただろうと考えられます。 まとめ PHP5を利用していて、DBの抽象化を行いたいのであれば、PEAR系のモジュールはやめてPDOにした方が良いと言えます。 単純なSELECT文の結果でさ
MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
