ちょっと使えるMySQLの小技5つ+1
こんにちは。最近ガスを止められ温もりの無い生活を送っている松田です。 今回は最近自分が知ったMySQLの小技をいくつか書いてみます。 んなもん常識だろ！ってネタがあっても優しく見守ってあげてください。 まず今回の実行サンプルには以下のテーブルを使ってます。 mysql> SELECT * FROM user_m; +---------+----------+---------------------+ | user_id | name | create_datetime | +---------+----------+---------------------+ | 1 | atsushi | 2007-05-17 21:53:40 | | 2 | joe | 2007-05-17 21:53:59 | | 3 | masah
Yahoo!オークションでのMySQL 冗長化技術
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMS の MySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
Distribution Awareness - MySQL Clusterにおけるスキーマチューニングの定石
MySQL Clusterはデータノードが増えると性能が低下する？？？ そのような噂を聞いたことがないだろうか。この噂は事実を含んでいる面もあるが、殆どの場合は適切にスキーマを設計していないことが原因で起きる。実はMySQL Clusterはその性能を遺憾なく発揮するためにはスキーマの設計が非常に大事なのである。 MySQL Clusterは複数のデータノード（ノードグループ）に対して主キーの値に基づいて行単位で分散されている。主キーに偏りがなければ各データノードに格納される行数は均等になる。つまり、MySQL ClusterはSharding（アプリケーションパーティショニング/Level2分散）を自ら行っていると言えるだろう。 MySQL Clusterでは主キーによるルックアップは、どのデータノードにデータが格納されているかが主キーから分かるため非常に高速である。逆に、主キー以外のキ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 4.5.1.2 mysql クライアントコマンド
mysql は、ユーザーが発行する各 SQL ステートメントを、実行のためサーバーに送信します。 mysql 自体が解釈するコマンドもあります。 これらのコマンドのリストを表示するには、mysql> プロンプトで help または \h と入力します。 mysql> help List of all MySQL commands: Note that all text commands must be first on line and end with ';' ? (\?) Synonym for `help'. clear (\c) Clear the current input statement. connect (\r) Reconnect to the server. Optional arguments are db and host. delimiter (\d) Set
MySQLのベンチマークを用いたIntel X25-M SSDの評価 - SH2の日記
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (本記事) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (2009/09/07) 先週末IntelのSSD、X25-Mが突然7,000円ほど値下がりしたので、ついに我慢できず手を出してしまいました。初めてのSSD導入です。 SSDのベンチマーク記事は国内・海外問わずたくさんありますが、実際にデータベースを乗せて計測した記事はそれほど多くありません。そこで、先日ご紹介したtpcc-mysqlを用いてベンチマークテストを行ってみました。 データベースサーバ OS ： Windows XP SP3 32bit CPU ： Core2 Duo T7300 2.0GHz (EIST OFF)
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
MySQLのプロンプトを変更する。
MySQLのCLI（コマンドラインインターフェイス）を利用しているとおなじみの mysql> というプロンプトがあるが、実はこれは変更が可能である。MySQL CLIを利用している最中なら、promptコマンドを実行すれば良い。例えば次のように。 mysql> prompt \U [\d] >\_ PROMPT set to '\U [\d] >\_' mikiya@localhost [test] > \Uや\dはそれぞれ意味が決まっていて、それらを組み合わせることで任意の情報をプロンプトに表示できるわけである。見易いように > やスペース、括弧などを組み合わせるといいだろう。例えば何かの作業をするときには mysql> prompt 作業1 [\D]>\_ PROMPT set to '作業1 [\D]>\_' 作業1 [Tue Mar 17 07:39:28 2009]> などとする
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
［MySQLウォッチ］第26回 知らないではすまされない，MySQLのセキュリティ設定
データベースのセキュリティ設定は，標準のSQLステートメントを使用して行うものだ。そのため，どのデータベースでも同様に行えるのが建前だ。しかし，それぞれのデータベースごとにユーザーIDの取り扱いなどで異なる点があり，実施には大きく異なる。今回は，MySQL 5系も含めてセキュリティ設定に関して解説する。 ユーザーID MySQLのユーザーIDは，ユーザー名とホスト名の組み合わせとなっている。ユーザーID自身にどのホストからアクセス可能なのか明示しているので，わかりやすい面がある。「%」は，ワイルドカードとなっている。そのためホスト名に指定すれば，ホストを特定しないユーザーIDとなる。 次の例では，同じユーザー名で4つの例を挙げている。 ユーザーIDの例 satou@'%' すべてのホストからアクセス可能 satou@localhost ローカルホスト(サーバーそのもの)のみアクセス可能 s
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
Runtime error - webframe
Error message : Directory is not found or not writable (DATA_DIR) Directory is not found or not writable (DIFF_DIR) Directory is not found or not writable (BACKUP_DIR) Directory is not found or not writable (CACHE_DIR) Site admin: whitestar Copyright © 2006-2023 whitestar. All Rights Reserved. Icons powered by famfamfam. PukiWiki 1.5.0 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL
MySQL演算子・関数
MySQLの演算子や関数について説明します。 なお、個人的に必要無いと思うものについては省略しています(笑)。 MySQL5.0.16対応 最初に MySQLでは、数値⇔文字列の変換は自動的に行われます。 SELECT 100 + '200' -> 300 SELECT 100 < '200' -> 1 (TRUE) SELECT 100 < '22' -> 0 (FALSE) 比較演算子 比較演算の結果は、1(TRUE) / 0(FALSE) / NULL のいずれかになります。 例を挙げます。 SELECT 1 = 1 -> 1 SELECT 1 = 3 -> 0 SELECT 1 = NULL -> NULL SELECT NULL = NULL -> NULL 最後の結果に注意して下さい。 どのデータベースにも共通して言えることですが、NULLという値は 特別な意味を持ちます。 N
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
Perl Tips | MySQL で、重複レコードを抽出する方法
株式会社アンタス - 次の時代のマーケティングテクノロジーを
