カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09Mikiya Okuno

MySQLの昇順ソートの問題 それは、昇順でソートすると、基準カラムがNULLの場合、それが先頭に来ることだ。実装としては正しいかもしれないが、NULLが最後に来てほしい場合もある。 しかし、MySQLには(少なくとも4.1系には)それを指定するオプションがない。よって、昇順にソートすると次のようになる。 例：面接に予約した学生を予約日順に昇順ソートする SELECT students.id,held_date_time FROM students LEFT JOIN interviews on students.interview_id = interviews.id ORDER BY held_date_time; +----+---------------------+ | id | held_date_time | +----+---------------------+ | 2

別ブログに書いてたものをまとめてみました。 case_sensitiveで大文字と小文字を区別・・・できない - おもしろWEBサービス開発日記のrailsメモ - railsグループ 昔の仕様 これまで、mysqlを使用しているとき、値の唯一性をチェックするvalidates_uniqueness_ofメソッドの:case_sensitiveはtrueにしても大文字小文字の区別はつきませんでした。理由はmysqlがデフォルトでは大文字小文字を区別していないからで、回避方法としては該当テーブルのmigrationファイルに execute("ALTER TABLE users MODIFY login varchar(255) BINARY NOT NULL") のように書いてカラムにBINARY性質をつけるか、SELECT文中にBINARYをつけてやる必要があります。 最近の仕様 これま

平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識

mysqlでは、collate = utf8_unicode_ciを指定すると、大文字-小文字だけでなく、全角-半角を同一視できるそうですが、実際にどの文字が同一視されるのかを試してみました。 collateとは http://tetlist.info/2009/01/mysql ↑このエントリでも分かりやすく紹介されていますが、collate(照合順序)とは、文字を比較(一致/不一致や表示順)する際のルールです。 utf8_unicode_ciで大文字-小文字だけでなく、全角-半角を同一視 mysqlのデフォルトcollateであるutf8_general_ciでは、大文字-小文字を同一視しますが、utf8_unicode_ciでは、さらに半角-全角も同一視します。 ※ci とは Case Insensitive の略称のようです tableやcolumn自体にcollateを設定する

Rails でユニーク制約を行うためには、モデルに validates_uniqueness_of を設定して、スキーマでユニークインデックスを設定しておくという話を書きました(https://tmtms.hatenablog.com/entry/20120602/rails_unique)。 が、それだけでは十分ではありませんでした。また軽くハマったのでメモしておきます。 ユニーク項目の値が既存かどうかを調べるためのクエリは次のようになっていました。 SELECT 1 FROM `users` WHERE `users`.`login` = BINARY 'hoge' LIMIT 1 よく見ると BINARY というキーワードが指定されています。これは大文字小文字を区別して比較するという指定です。 ところが MySQL はデフォルトでは大文字小文字を区別しません。 モデルは大文字小文字を

問題 select * from member where namae like '%サトウ%'; こんなSQLで、namaeがサトウ、ｻﾄｳ、さとう、サトｳ（一部半角）何でもマッチさせたい！ 答え では、これで。 select * from member where namae collate utf8_unicode_ci like '%サトウ%'; データベースがutf8でないときは、もうひとつ変換を入れて、 /* ERROR 1253: COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'ujis' など言われたら */ select * from member where convert(namae using utf8) collate utf8_unicode_ci like '%サトウ%'; 数字の全角/半

まだMySQL 5.6が登場して興奮冷めやらぬところだが、MySQLの開発チームはその手綱を緩めることはない。次期バージョンの開発版であるMySQL 5.7.1がすでに登場している。MySQLの開発リリースモデルではマイルストーンリリースと呼ばれるマイナーバージョンごとに新しい機能が盛り込まれる。（参照：MySQL 5.5登場）MySQL 5.6系での最後のマイルストーンリリース、つまり新しいバージョンが盛り込まれたバージョンがマイルストーン9、そして5.7.1がマイルストーン11となる。（マイルストーン10、つまり5.7.0はリリースされていないバージョンとなっている。）MySQL 5.7が正式版になるまでに、いくつのマイルストーンリリースを経るか、つまりどれだけ新機能が搭載されるかについては今のところ未定だが、新しいバージョンのリリースが待てない！という人はぜひMySQL 5.7.1を

ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ

ターミナルから mysql -u root -p で、MySQLを起動しようとすると ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) っていうエラーが。 このエラーをもとにぐぐってみて、(こことかを参考に) MySQLサーバーが起動していない MySQLサーバーで使っているUNIXソケットとクライアントソフトで使っているUNIXソケットのパスが違う なんらかの理由でソケットファイルが削除されている 特に起動できなくなった直前にmy.cnfとかいじった覚えないし、ソケットファイル格納ディレクトリのパーミンションも問題なさそう... いろいろ試行錯誤した結果、よくわからんので再インスコ。。。 次にここを見てみた。 とりあえずrootのパスワード設定 mysq

MySQL5.5系がデフォルトでレプリケーションが有効に。 あー、悲しい 以前、MySQL5.1から5.5にバージョンアップして、放置していたら 知らぬ間にディスク容量がいっぱいに。。 何が起きた！？と思っていて調べてみると MySQL5.5系がデフォルトでレプリケーションが有効になっているらしい。 http://www.mk-mode.com/wordpress/2012/05/23002009/ 知らなかった。。 ということで、自動削除の設定を行い事なきを得ましたが、 最初はMySQLの障害のような動きで、わけわからない状態に陥ったので 行動ログを記録した↓今度何か起きたら参考にしよう。。 追跡編 [mysql-user]# mysql --version mysql Ver 14.14 Distrib 5.5.19, for Linux (x86_64) using EditLine