Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
CentOS6系からCentOS7系への移行案件があり、そこでMySQL-5.1からMariaDB-5.5への移行を行う必要がありました。 他にも色々と変わる部分があるため、一旦動作テスト用のサーバを作って確認することになり、データの移行を行いました。 そのとき、アカウント情報の移行ではまったのでメモしときます。 まずアカウント情報は普通にフルダンプしても取れないため、下記のようにmysqlテーブルを指定して取ります。 正式移行の際には -x オプション付けてロックしたほうがよいでしょう。 # mysqldump -u root -p --allow-keywords mysql > user_dump.sql その後、テスト用サーバにコピーしてリストアします。 # mysql -u root -p mysql < user_dump.sql 自分はもうこれだけでいいのかな、と思っていたの
問題 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 で max_allowed_packet を超過した場合にどうなるんだっけ…と思って試してみた結果。 サーバーの max_allowed_packet をクエリが超過した場合 MySQL 5.6 サーバー起動 % docker run --name mysql56 -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -d mysql:5.6 --max-allowed-packet=100000 クライアントは原因がわからないけど切断される % ruby -e 'puts "set @a="+"1"*1000000' | docker exec -i mysql56 mysql ERROR 2006 (HY000) at line 1: MySQL server has gone away サーバー側はログ出力なし % docker logs mysql56 .
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
自分は全然気にしたことなかったんだけど、MySQL の NOW() と SYSDATE() は異なるらしい。 sakaik.hateblo.jp MySQL 8.0 のマニュアル (https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_sysdate) にも確かにちゃんと書かれてる。 SYSDATE() returns the time at which it executes. This differs from the behavior for NOW(), which returns a constant time that indicates the time at which the statement began to execute. (Within a stored fun
「MySQL徹底入門 第4版」が 7/6 に発売される。🎉 www.shoeisha.co.jp 電子書籍は翔泳社の直販がDRMフリー(たぶん)だからオススメ。 著者用見本誌も届いたので、さすがにこれからやっぱり発売できませんでした!ってことにはならないと思う。 長かった。 本当は去年出る予定だったんだが、なんやかんやで今年になった(よくある)。 第3版が出たのが 2011年だから、実に9年ぶり! 偶然にも第3版と同じ 544ページなんだけど、1ページ辺りの文字数は増えているので情報密度は増しているはず(そしてその分価格も上がってる)。 (ただしくは552ページらしい。) 「MySQL徹底入門」は第n版が出るたびに、毎回ほとんどを書き下ろしてるし、複数人で書いてるんだけど、書いてる人も入れ替わるし担当する章も変わる面白い本。 自分は、今回は第5章「ユーザー管理」、第10章「データベースプ
新元号が「令和」に決まったことなので、MySQLでの扱いについての話を。 普通の文字 「令」も「和」もJIS第一水準に含まれている基本的な文字なので普通に日本語が使用できるcharsetで使用できます。 mysql> create table t ( utf8mb4 varchar(255) charset utf8mb4, utf8mb3 varchar(255) charset utf8mb3, utf16 varchar(255) charset utf16, utf32 varchar(255) charset utf32, cp932 varchar(255) charset cp932, eucjpms varchar(255) charset eucjpms, sjis varchar(255) charset sjis, ujis varchar(255) charset
GROUP BY 句を満たすもっとも一般的な方法は、テーブル全体をスキャンし、各グループのすべての行が連続する新しい一時テーブルを作成することであり、それにより、この一時テーブルを使用してグループを見つけて、集約関数 (ある場合) を適用できます。 場合によっては、MySQL はそれよりはるかに優れた処理を実行でき、インデックスアクセスを使用した一時テーブルの作成を回避できます。 GROUP BY のインデックスを使用するための最も重要な前提条件は、すべての GROUP BY カラムが同じインデックスの属性を参照し、インデックスにそのキーが順番に格納されることです (たとえば、BTREE インデックスの場合は該当しますが、HASH インデックスの場合は該当しません)。 一時テーブルの使用をインデックスアクセスに置き換えられるかどうかは、クエリー内でインデックスのどの部分が使用されているか、
MySQLのutf8 charsetは、やれ「罠」だの「絵文字が入らなくて使えない」だの「utf8という名前はutf8mb4の別名にすべき」だの、散々な言われようでディスられてかわいそうな charset なんだけど、というか主に私がそう言ってる気もするんだけど、そろそろ utf8mb3 のエイリアスとしての utf8 は消え去ろうとしてるみたいなので、ここでちょっと勝手にフォローしておく。 UTF-8 エンコーディングの RFC は RFC3629で、ここで UTF-8 は最大4バイトと書かれている。 しかし、この RFC3629 の前のRFC2279では6バイトだった。 RFC3629 の日付は 2003/11 なので、つまり 2003/11 よりも前は UTF-8 の1文字のバイト数は最大6バイトだったのだ(少なくともRFC上では)。 MySQL が Unicode に対応したのはバ
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
$ mysql -h127.0.0.1 -P13306 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 $ sudo less /var/log/mysqlrouter/mysqlrouter.log 2018-02-21 12:27:25 INFO [7fe221c14700] [routing:test] started: listening on 127.0.0.1:13306; read-write 2018-02-21 12:27:39 WARNING [7fe213fff700] Timeout reached trying to connect to MySQL Server xxxx:3306: Con
MySQLのデーターベースをバックアップするのは割と簡単なんですが、実は登録されたユーザー情報は別にバックアップしないといけないんですよ。 先日、そのことを知りました。 こういう情報って、こういうブログにちゃんと書いておいたほうがいいですよね。 と言いつつ、なかなか書きそびれていたんですが。 具体的にはこんな感じ。 mysqldump -u root-p -x --all-databases > hogehoge.dump mysqldump -u root -p -x --allow-keywords mysql > hogehogeuser.dump 上の1行でデータベース全体のバックアップをします。 下の1行でユーザー情報をバックアップします。 リストアは以下のとおり。 mysql -u root -p < hogehoge.dump mysql -u root -p mysql <
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く