MySQLのオペレーションを少しでもカジュアルにする方法 - カイワレの大冒険 Third
MySQL Casual Advent Calendar 2011の補欠記事でございます。折角申し込んだので、書いた次第でございます。 CASE文とは、という話しを書こうと思いましたが、カジュアルにやめましたよ！ そんな話はさておき、タイトルから見る限り、日本語でおｋと言われそうですが、単に毎日触れている作業を少しでも軽減できたらいいですよね、ということでカジュアル（気軽）にMySQLと戯れる方法を書いてみたいと思います。 情報足りねーよって場合 まずはデフォルトのプロンプトですね。 こんな感じ。色気がないですな。 なので、味をつけてみましょう。 sugyanさんも6日目の記事で触れていましたが、MySQLでは「MYSQL_PS1」という環境変数を利用できます。なので、.bashrcとかに以下のように書いておくと、MySQLのプロンプトにお好みの情報を加えることができます。 ここで使えるオ
サクっと MySQL のレコードの値を置き換える方法
MySQL のレコードの値を置き換えることができます。例えば以下は 0 という数値を 12 に置き換えます。
mysqlのindex(key)は、nullありで指定しても結局nullレコードもindexされる - manjuphobiaの日記
たまに忘れるので、メモ。 mysqlのindex(key)は、nullありで指定しても結局nullレコードもindexされる。 col_name IS NULLを使用した検索では、col_nameにインデックスが張られている場合にインデックスが使用されます。 MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.3.1 MySQL のインデックスの使用の仕組み これの何が問題なのかと言えば、一般的(SQL標準的？)にはNULLはインデクスされないものであり、相変わらずmysqlの動作がsql標準から微妙にずれているということである。 sqlの仕様は２・３万するのでちょっと読めていないが、多分sql標準を読んでいるだろう人の記事を引用。 また一般的に，B-treeはNULLをキー値として保持しないため，IS [NOT] NULLを指定した場合もインデックスは使われません。
MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
レプリケーション作成を簡単にする mysql40dump という mysqldump の wrapper を作った話 - blog.nomadscafe.jp
みなさん mysqldump は好きですか？ 自分はどっちでもありません。 MySQLでよくあるMaster-Slave構成を作る手順は以下のようになると思います MasterからSlaveとなるサーバに一貫性を保った状態のコピーをし、そのデータのバイナリログのファイル・ポジションをメモ。 SLAVEでデータをリストアし、Masterのホスト名、レプリケーションに使うユーザ名・パスワードとメモしたバイナリログのポジションをCHANGE MASTER文に渡し、START SLAVE 一貫性の取れたコピーを作成するためにmysqldumpやxtrabackup、LVMなどでのスナップショットが利用できますが、もっとも簡単な方法がmysqldumpだと思います。 mysqldumpで一貫性のあるデータをとり、その際のバイナリログポジションを記録するには $ mysqldump --single-
第3回 ループ依存症～手続き型の呪縛を打ち破れ！ | gihyo.jp
ここはとある街の総合病院。 ここには通常の診療科のほかに、一風変わった診療科が存在する。 何軒もの病院をたらいまわしにされた、手の施しようのないSQLや、今すぐに改善が必要なSQLが担ぎ込まれる救命室である。 それがSQL緊急救命室、略してSER（SQL Emergency Room）。 そう、ここは国内でも唯一のプログラミング専門外来である。 ロバート救命室部長。腕の立つエンジニアだが、口が悪く性格はもっと悪い四十オヤジ。 SQLを学ぶ上で最も高いハードルとなるのが、順序と手続きではなく、集合と論理の観点から考えることだ。 ―J.Celko『Joe Celko's SQL Programming Style』 （Morgan Kaufmann、2005年）p.184 ループによる表現 （PM3:00 手術室。先ほどかつぎ込まれたばかりの患者を前にして、何やら揉めている） ワイリー、
Senna 組み込み型全文検索エンジン - Senna 組み込み型全文検索エンジン
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
SQL改善によるパフォーマンス向上 - mic_footprints
事例 実際にアプリケーション開発を行っていて、検索機能を実装していたときに超絶重い検索ロジックに出会いました。 その対処をSQL文の改善で行なったので紹介します。 データ構造 環境 MySQL 4.1 mysql> DESCRIBE users; +-------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | name | varchar(40) | YES | | | | +-------+-------
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQLのチューニングのヒント集｜株式会社 フラッツ
谷口です。 MySQLがボトルネックになっている場合のチューニングをするときに、私が役立てているサイトをまとめました。 非常にありがたい情報が多くて助かってます。 SQLを速くするぞ―お手軽パフォーマンス・チューニング クエリチューニングのヒントになります。MySQLに限らず他のDBMSでも通用するTipsです。 Web高速化 | パフォーマンスチューニングblog | インターオフィス InnoDBとMyISAMの比較が充実してます。 MySQLのパフォーマンスチューニング - Absolute Playing! InnoDB、MyISAMの各設定など基本的なことがよくまとまっています。 MySQL :: MySQL 4.1 リファレンスマニュアル :: 4.6.8.4 SHOW VARIABLES MySQL4系のリファレンス。各パラメータの説明があります。 MySQL :: MyS
MySQL/チューニング - がしまっくす
統計情報を取る † 定量的な情報収集のススメ mysql> show global status; (5.0.2以上の場合) mysql> show status; (5.0.2未満の場合) ↑ ファイルオープン数の調整 † 高負荷なときに以下のコマンドを実行 $ mysqladmin -u root -p extended-status | grep Open Enter password: | Open_files | 515 | | Open_streams | 0 | | Open_tables | 256 | | Opened_tables | 45281 | Open_files, Open_tablesの数が多い場合は /etc/my.cnf の以下を調整。この値が大きすぎると「Error in accept: Too many open files」エラーが発生し、MyS
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
SQLパフォーマンス問題調査でEXPLAIN PLAN、SQLトレースは（ほとんど）使わない « WR blog
December 2014 (1) February 2014 (1) January 2014 (1) September 2012 (1) April 2012 (1) March 2012 (2) October 2011 (1) June 2011 (5) May 2011 (1) April 2011 (1) March 2011 (1) February 2011 (1) January 2011 (1) December 2010 (1) September 2009 (1) April 2009 (1) March 2009 (1) January 2009 (3) November 2008 (2) October 2008 (1) December 2005 (2) October 2005 (2) September 2005 (2) August 2005 (7)
DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） - 主に言語とシステム開発に関して
データベースには，「トランザクション分離レベル」というものがある。 以下では，それが なぜ必要なのか？ デフォルトのレベルでは，どうして駄目なのか？ PostgreSQLでは，どうやってレベルを変更・確認するのか？ などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは： 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか，のレベル。 ANSI規格では，４つのレベルがある。 READ UNCOMMITTED （一番低い） READ COMMITTED REPEATABLE READ SERIALIZABLE（一番高い） 徹底比較!! PostgreSQL vs MySQL 第３回：トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://atnd.org/events/22528
MySQLを通じた全文検索エンジンSenna/groongaの利用について
MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボ
サービス終了のお知らせ