mysql_options(mysql, MYSQL_SET_CHARSET_NAME, cs_name) だけして mysql_real_connect(mysql, ...) した後SHOW VARIABLESしてみたら接続のcharsetが設定済みの挙動をするんやけどmysql_real_connectからの一連のコード読んでもどこでそれが起きるのかわからん誰かたすけて🥲https://t.co/ZScoD3tIQ8— Ryuta Kamizono (@kamipo) February 20, 2021 MySQLのハンドシェイクパケットにcollation_idを1バイトだけ入れられるところがあって、charset name のデフォルトの collation_id を送っています。 クライアントとサーバーのバージョンが違うとデフォルトのcollation_idが違うことがあって

Deprecatedにした経緯というか背景が伝わってるのかどうかアレだと思ったので、ここに日本語にて書き記しておく。 Deprecate mismatched collation comparison for uniquness validator by kamipo · Pull Request #35350 · rails/rails · GitHub Active Recordのuniqueness validatorはデフォルトでcase sensitiveな比較をするんですが、これが、文字列のデフォルトのcollationがcase insensitiveなMySQLと相性が悪く、DB上のUNIQUE制約と一致しない振る舞いだったりINDEXが効率よく使えずDBが死ぬみたいな問題を引き起こしていました。 例: 本当にあったRailsの怖い話 僕も主に仕事のコードレビューで過去に何

4月にMySQL 8.0のUnicodeと日本語対応についてManyi Luさんとディスカッションする会があって、かなりいろいろ話してとてもよい会だった。その後いろいろ考えて感じてる懸念を端的に書き記しておく。 デフォルトのcollationがutf8mb4_0900_ai_ciになった これに関して僕は強い懸念を持っている。MySQL 8.0以前において、ふつうのWebアプリケーションなどで日本語を扱う場合、実用上デフォルトのutf8mb4_general_ciかutf8mb4_binの2択であったと思う。デフォルトがutf8mb4_general_ciなので新しく作られるアプリケーションは通常は濁点半濁点が区別される状態で世に出てくることになる。けどMySQL 8.0.1のデフォルトのutf8mb4_0900_ai_ciは濁点半濁点を区別しないので、将来ユーザー名を登録するところでバイ

MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select

毎回わからなくなってググってるから今度からここに追記していく。 MySQL PostgreSQL SHOW DATABASES; \l USE dbname \c dbname SHOW TABLES; \dt SELECT * FROM tblname\G \x on SELECT * FROM tblname; SELECT * FROM information_schema.processlist; SELECT * FROM pg_stat_activity; KILL <pid>; SELECT pg_terminate_backend(pid); KILL QUERY <pid>; SELECT pg_cancel_backend(pid); table / column の情報 MySQL PostgreSQL SHOW TABLE STATUS FROM dbname; わ

この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン

もうMySQL 5.5 GAが出てから１年以上が経ち、つい先日とうとうMySQL 5.6 GAも出た昨今、これから先パーソナルユースでこれより以前のMySQLなど使うことはないだろうと~/.my.cnfを書いていたのだけど、昨日ちょっとしたアレでMySQL 5.1を入れたらMySQLが進化しすぎててオプションコメントアウトしまくらないと動かないわーとかいってたらloose-つけるといいですよって教えてもらった。 my.cnfのオプション名の頭にloose-と書いておくと、オプションが存在しなくてもWARNINGでERRORにならずに済みますよー。loose-log-slow-queriesloose-slow-query-logと書くと5.1でも5.5でも使える、みたいな。— ts. yoku (@yoku0825) February 6, 2013 これは知らなかった！ MySQL 5.