mysqlの可変長文字列を扱う、varchar型とtext型の違いの話。 古い情報が混在していたので、ちょっと整理してメモ。 myisamの頃の話 sizeが違う 行の中身がdataか(varchar)、dataへのポインタか(text) 参照挟むので、performanceの違いがあった(varcharが早い) 今 net でぐぐって、ひっかかる情報の大半がこの話。 最近のinnodbの話 最大sizeは一緒。64kb(但し、TINYTEXT型、MEDIUMTEXT型、LONGTEXT型は名前の通り違う) varcharもtextも、中身は同じ仕組み(BLOB field / off page column) 行にdata入れるのも、外部(overflow page)への参照にするのも、行フォーマット次第(row format) 5.6で行formatのdefault は COMPACT
これまで Amazon EC2 で動かしていた1日1回動作する Ruby で書かれたバッチを、主にコストダウンを目的として AWS Lambda に移行し、サーバーレス化した。 バッチの内容としては、RDS で稼働している MySQL のデータベースから必要なデータを取得する必要がある。 バッチの内容をできるだけ書き換えずに AWS Lambda から Amazon RDS へ接続する際に、少し手順が複雑だったので、今回はその方法を備忘録も兼ねて整理しながらやってみる。 作業ディレクトリ作成 まずは作業ディレクトリの作成。 今回は、mysql2_test とした。 $ mkdir mysql2_test $ cd mysql2_test Dockerfile 作成 Mysql2 の gem を動かすためには、mysql-devel のインストールが必要となる。 Dockerfile を下記
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
しょっちゅう忘れるのでメモ。 mysqlに切り替え USE mysql 登録されているユーザを確認 SELECT user, host FROM user; 権限を表示 SHOW GRANTS for 'hoge'@'%'; ユーザを作成 CREATE USER user_name; CREATE USER user_name IDENTIFIED BY [PASSWORD] 'password'; ※ユーザ指定の書式例 user_name@host_name ※ワイルドカードをホストに使うときはシングルクォートでくくる user_name@'%' 'username'@'192.168.128.%' 権限付与 GRANT ALL PRIVILEGES ON `DB名`.テーブル TO 'ユーザ名'@'ホスト名'; GRANT SELECT,UPDATE,INSERT,DELETE ON
mysql> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | |
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
Today’s bug: I tried to store a UTF-8 string in a MariaDB “utf8”-encoded database, and Rails raised a bizarre error: Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1This is a UTF-8 client and a UTF-8 server, in a UTF-8 database with a UTF-8 collation. The string, “😃 <…”, is valid UTF-8. But here’s the rub: MySQL’s “utf8” isn’t UTF-8. The “utf8” encoding only supports th
$ sw_vers ProductName: Mac OS X ProductVersion: 10.14.2 $ ruby -v ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17] $ rails -v Rails 5.1.2 Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /Users/{username}/rails_app/test-mysql/vendor/bundle/gems/mysql2-0.5.2/ext/mysql2 /Users/{username}/.rbenv/versions/2.5.1/bin/ruby -I /Users/{username}/.rbenv/versio
絵文字（UTF-8 の 4 byte 文字にあたる）を利用可能とするため、文字コードは utf8mb4 を利用する。 絵文字だけでなく非常用漢字なども対応するためには必要。 サーバ設定 とりあえず開発環境（Mac）は Homebrew でインストール brew install mysql （検証時点で 5.7.13）。 サーバの設定を以下のとおり変更する。 $ diff /etc/my.cnf.org /etc/my.cnf --- /etc/my.cnf.org 2016-07-05 18:46:02.000000000 +0900 +++ /etc/my.cnf 2016-07-15 14:43:47.000000000 +0900 @@ -16,7 +16,7 @@ # The following options will be passed to all MySQL clients
⚓ utf8の4バイト文字問題は突然に こんにちは、hachi8833です。 MySQLのデータベースでencoding=utf8が指定されていると、UTF-8の文字長が4バイトの文字をデータベースに保存できなくなる、いわゆるUTF-8の4バイト文字問題、またの名を「寿司ビール問題」が発生することがあります（「MySQLのutf8の4バイト文字問題とは」で後述）。 BPSWebチーム部長のmorimorihoge さんがこの問題に対応したときの手順をメモします。 ⚓ utf8からutf8mb4に移行する手順 MySQLのストレージエンジンはInnoDBが前提です。utf8mb4を指定するにはMySQLのバージョンが5.5以上である必要があります。 ⚓ 1. 以下のコマンドでdumpを取る mysqldump --no-create-info --ignore-table=mydata_st
Gem files will remain installed in /Users/user_name/Programs/web/test-repo/vendor/bundle/ruby/2.3.0/gems/mysql2-0.4.4 for inspection. Results logged to /Users/user_name/Programs/web/test-repo/vendor/bundle/ruby/2.3.0/extensions/x86_64-darwin-15/2.3.0-static/mysql2-0.4.4/gem_make.out An error occurred while installing mysql2 (0.4.4), and Bundler cannot continue. Make sure that 'gem install mysql2 -
こんにちは、みかみです。 今日のクラスメソッドのAWSおみくじ、RDS（t1.micro）でしたー！（昨日は Aurora！＠＠ｖ はじめに 前職＠アプリ開発時、MySQL のクエリチューニングをさせていただく機会がありました。 ユーザー入力のキーワードで全文検索 → 見つかったレコードを返すのですが、所要時間、約3分。。 Apache タイムアウトして画面真っ白。。。（泣きそうでした＞＜。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリの
mysql> use utf8mb4_sample_development; mysql> show variables like "chara%"; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesyste
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[MySQL] 文字コード問題 -みんな大好き寿司ビール🍣🍺- - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/1d4b6f549cdf7a7e42d540233462c9caf6f29f1a/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMTQ2NjkzJTJGcHJvZmlsZS1pbWFnZXMlMkYxNDk2MjE4Mjk2P2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZiZz1GRkZGRkYmZm09cG5nMzImcz0zZmY3M2FlNTdmOTMyYmQ4MmQyZGNhNzJiNGRhYzZjMw%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D1f0ffacfa627c32d760ff66faadfb1dd%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCTXlTUUwlNUQlMjAlRTYlOTYlODclRTUlQUQlOTclRTMlODIlQjMlRTMlODMlQkMlRTMlODMlODklRTUlOTUlOEYlRTklQTElOEMlMjAtJUUzJTgxJUJGJUUzJTgyJTkzJUUzJTgxJUFBJUU1JUE0JUE3JUU1JUE1JUJEJUUzJTgxJThEJUU1JUFGJUJGJUU1JThGJUI4JUUzJTgzJTkzJUUzJTgzJUJDJUUzJTgzJUFCJUYwJTlGJThEJUEzJUYwJTlGJThEJUJBLSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTgzOWYwYzRlOWYyYmYwNWE3YWNiZjg2YjA0YzM1MzU0%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBtYW15MTMyNiZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWRlNjQxM2YwOGEzMGQzNjE4ZDUzOTJiNWNmMDdmNGZk%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D3cd6f2661b81d4ef2ea69698585e0bca)
