default_collation_for_utf8mb4 なんてパラメーターが追加になっていた何このパラメーター、と思ったら、 utf8mb4 のデフォルトコレーションが utf8mb4_general_ci (MySQL 5.7とそれ以前) から utf8mb4_0900_ai_ci (MySQL 8.0)に変わったことに対する経過措置っぽかった。 これを utf8mb4_general_ci にセットしておくと、コレーションを指定せずに utf8mb4 を使った時に今まで通り utf8mb4_general_ci を使ってくれるということ。 mysql80 13> SELECT @@default_collation_for_utf8mb4; +---------------------------------+ | @@default_collation_for_utf8mb4 | +---------------------------------+ | utf8mb4_g
ブックマーク / yoku0825.blogspot.com (25)
-
a2ikm 2018/05/29
-
割と安全にpt-online-schema-changeとかpt-table-checksumを取るための簡単なやり方
マスター/スレーブ構成（そもそもスレーブいなければcheck_slave_lagもへったくれもない） pt-osc, pt-tcsなどはマスターサーバーで実行する check_slave_lag用にユーザーを作る（図の実線部分を担当するためのアカウント） 短期間でDROPするのが前提で、色々面倒なのでスーパーユーザーで行く。FILE権限くらいは確実に要らないからREVOKEしとくか。。
-
MySQL 8.0.1でutf8mb4_ja_0900_as_csが導入された
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog （ユーザーによる日本語訳: 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst）で言及されていた日本語用の照合順序 utf8mb4_ja_0900_as_cs 。 mysql80> SHOW COLLATION LIKE 'utf8%ja%'; +-----------------------+---------+-----+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-----------------------+-
-
information_schemaでちょこちょこ使えるTIPS
ちょこちょこ使うi_s関連のSELECTステートメント。 やる前にSET GLOBAL innodb_stats_on_metadata= 0; しておかないと重くなる。 mysql56> SELECT CONCAT(table_schema, '.', table_name) AS object, column_type FROM columns WHERE column_name= ? ORDER BY 1, 2; mysql56> SELECT CONCAT(table_schema, '.', table_name) AS object, index_name, GROUP_CONCAT(column_name ORDER BY seq_in_index) AS columns FROM statistics WHERE table_schema NOT IN ('mysql',
-
WHERE .. IN (..)のリストの順番でソートするORDER BY FIELDの仕組み
MySQLには`WHERE col IN (..) ORDER BY FILED(col, ..)`という書き方でINに並べた順番にソートしなおせるという知見がある。 こんなテーブルがあって、 mysql56> SELECT * FROM t1; +-----+-------+ | num | val | +-----+-------+ | 1 | one | | 2 | two | | 3 | three | | 4 | four | | 5 | five | | 6 | six | | 7 | seven | | 8 | eight | | 9 | nine | | 10 | ten | +-----+-------+ 10 rows in set (0.00 sec) INにテキトーな値を並べてやっても、 mysql56> SELECT * FROM t1 WHERE num IN
-
MySQL 5.7.8から導入されたVersion Tokenとやらの動作
ドキュメントはこちら。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.8.4 Version Tokens サーバーの持ってるトークンとクライアントが持ってるトークンを比較して、一致しなければエラーにしてくれる仕組み。 取り敢えず何はなくともインストール。version_token.soはバンドルされてるので、ドキュメントの通りにINSTALL PLUGINとCREATE FUNCTIONを貼り付ければOK。 mysql> INSTALL PLUGIN version_tokens SONAME 'version_token.so'; Query OK, 0 rows affected (0.00 sec) mysql> CREATE FUNCTION version_tokens_set RETURNS STRING SONAME 'version
-
pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け
この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc）もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージ食いつぶしそう または INSERT大杉で2
-
MySQL 5.7のmysql_upgradeは本当にDATETIME型を新しいフォーマットに直してくれるけれど
Upgrading Directly from MySQL 5.0 to 5.7 using an ‘In Place’ Upgrade | MySQL Server Blog を読んでふと思い立ったので。 MySQL 5.7のmysql_upgradeは古いDATETIME, TIME, TIMESTAMPを新しいDATETIME2, TIME2, TIMESTAMP2に変換してくれるからmysqldumpしてからリストアしなくてもいいんだぜ！ っていうのが趣旨らしい。それは素敵だ。 ↓これの12番目 日々の覚書: あなたのMySQL 5.6トレンド力をチェックする15の質問 ざっと見、確かにやってくれてる。worldデータベースを ダウンロード してきて食わせてみた。 （そういえば、昔はworldはMyISAMで、InnoDB版のworldが別にあったんだけど、今はたぶんInnoDBの
-
RESET SLAVEでリセットされる範囲
RESET SLAVEだけの場合、master_log_name, master_log_pos, ssl_verify_server_cert, heartbeat_periodのクリア。 RESET SLAVE ALLの場合、↑に加えてhost[0] = 0; user[0] = 0; password[0] = 0; される。 gtid周りの情報はhiroi10さんの gtidを使用した環境でのmysqldump が詳しい。 【2013/05/20 12:07】 MASTER_SSL_*は？ ⇒「メモリ上からは」クリアされない。 RESET SLAVEだけでもMySQL再起動したら消える気がするけど？ ⇒RESET SLAVEは「メモリ上の」↑の情報と、master.infoファイルを消す。 再起動するとメモリ上の情報は全て吹っ飛ぶ && master.infoから読もうにもmast
-
MySQL 5.7のinnodb_default_row_format 影響範囲まとめ
日々の覚書: MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです ではまだ5.7.9が手元になかったので推測でしたが、公開されたので試してみたまとめ。 |PRIMARY KEY|ALTER |変換|メモ | |-----------|-----------------|----|----------------------------------------------| |あり,なし |ADD COLUMN |Yes | | |あり,なし |DROP COLUMN |Yes | | |あり,なし |ADD FOREIGN KEY |Yes | | |あり,なし |ADD KEY |No |ALGORITHM= INPLACE | |あり,なし |ADD KEY |Yes |ALGORITHM= COPY | |なし |ADD PRIMA
-
MySQL 5.7.9のinnodb_default_row_formatがまた何か企んでいるようです
MySQL 5.7.9では innodb_default_row_format というサーバー変数が追加される（らしい。5.7.9はリリース前なので試せない） オンライン変更可能なグローバル変数なので、`SET GLOBAL innodb_default_row_format= ..'で変更も可能。暗黙のデフォルトは"Dynamic"。 名前と値から察せられる通り、kamipoさん の悲願をかなえる類のもの…なんだけれども、 MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる これ、 The innodb_file_format configuration option is ignored if a table is created
-
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 TL;DR kamipo traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。 これらの記事を読んだ人向けです。 ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。 +激しく同意+ さて、激しく同意したところで、kamipo traditionalでは倒せないMyISAMという名の化け物の話をしたいと思います。 kamipo tr
-
現代のMySQLはもう不要にINをEXISTSに書き換えない
漢(オトコ)のコンピュータ道: なぜMySQLのサブクエリは遅いのか。 この記事は 2009/3/25 に書かれたもののようである。 2009年3月といえばMySQL 5.1がGAになってわずか半年、MySQL 6.0.10-alphaがリリースされた頃で、MariaDBもまだ姿を見せていない頃だ。 時は流れて2015年、MySQL 5.6がGAになって早2年半、5.7のGAﾏﾀﾞｧ-? (･∀･ )っ/凵⌒☆ﾁﾝﾁﾝ な頃なので、もういい加減誰か言ってくれてもいいんじゃないかと思う。 もうMySQL(5.6)は不要にINをEXISTSに書き換えたりしないんだよって mysql51> EXPLAIN SELECT * FROM Country WHERE Continent = 'Asia' AND Code IN -> (SELECT CountryCode FROM City WHER
-
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
-
日々の覚書: MySQL 5.6以降でクライアントに "Warning: Using a password on the command line interface can be insecure." と言われるのを防ぐいくつかの方法
MySQL 5.6以降でクライアントに "Warning: Using a password on the command line interface can be insecure." と言われるのを防ぐいくつかの方法 MySQL 5.6以降では、同梱のクライアント(mysqlコマンドラインクライアント, mysqladmin, mysqldumpあたりがよくありそう)に-pオプションで直接パスワードを渡すと、 $ mysql56 -utest -ptest -e "SELECT current_user()" Warning: Using a password on the command line interface can be insecure. +----------------+ | current_user() | +----------------+ | test@lo
-
MySQL 5.7.6以降では暗黙のテンポラリーテーブルがあふれると死ぬ
MySQL 5.7.6から、JOINした時とかに作る暗黙のテンポラリーテーブルでMemoryストレージエンジンで収まらなくなった時に固定化するテンポラリーテーブル(Created_tmp_disk_tablesがカウントアップされるアレ)のストレージエンジンがInnoDBになった。 MySQL :: MySQL 5.7 Reference Manual :: 8.4.4 How MySQL Uses Internal Temporary Tables MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables テンポラリーテーブル用(こっちはCREATE TEMPORARY TABLEで作るやつも含んだ言い方だと思いねえ)のテーブルスペースはREDOロギングを無効化してあったりといいこともたくさんあるんだけれど、
-
MySQL 5.7.6でGTIDのローリング有効化ができるようになったので、システム全体を一度にシャットダウンしなくてもOK
MySQL 5.7.6でGTIDのローリング有効化ができるようになったので、システム全体を一度にシャットダウンしなくてもOK MySQL 5.7.6メモそのいくつか。 今までgtid-mode= ONとOFFのマスター, スレーブは混在できなかったので、ONにするときは一度レプリケーション群を全部止めて起動しなおさなければいけなかった。それが、出来るようになったという話。 MySQL Bugs: #71543: A new GTID_MODE is needed to evaluate/migrate to GTID: ANONYMOUS_IN-GTID_OUT. MySQL :: WL#7083: GTIDS: set gtid_mode=ON online Percona Server 5.6.22では一足先にリリースされてましたね。やってることは同じだけど実装が違うっぽい予感。 On
-
MySQL 5.7で絶対に必要になると思うlog_timestampsの設定
気づかなかったけど、これ5.7.2から入ってたのか。 フツーに扱うDATETIME型(やその親戚)は time_zone 変数に支配されるけど、ログに出力される時刻は log_timestamps 変数に支配される。 この変数の取りうる値は UTC または SYSTEM で、暗黙のデフォルトはUTC 。。 mysql57> SELECT @@version; +---------------+ | @@version | +---------------+ | 5.7.5-m15-log | +---------------+ 1 row in set (0.00 sec) mysql57> SHOW GLOBAL VARIABLES LIKE '%time_zone'; -- タイムゾーンはフツーにJST +------------------+--------+ | Variable_
-
MySQL 5.7で暗黙のデフォルトが変わりそうなはなし
Morgan Tocker というMySQLの中の人(MySQL Community Teamのひと)が 自身のブログ で、MySQL 5.7のデフォルト値の変更に関する意見を募集していたりする。 Proposed MySQL 5.7 defaults. Please send feedback! http://t.co/Uq6c7STXBE — morgo (@morgo) 2015, 1月 23 Proposal to change Replication and InnoDB Settings in MySQL 5.7 http://t.co/gr3AwwmoEv — morgo (@morgo) 2015, 1月 14 ので、ちょっと解説してみます。わたしが勝手に思っていることを述べているだけなので、詳しくは原文をあたってください。 まずはこっち。 Proposal to chan
-
過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去ること(仮)
過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去ること(仮) この記事は MySQL Casual Advent Calendar 2014 の3日目の記事です。 クソクエリーについての名言 がつい先週生まれたばかりですが、みなさま如何お過ごしでしょうか。そういえば今年は Kuso-query As A Code みたいな話もさせてもらいました。 過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去るため(仮)に、MySQL 5.7.5-labsのQuery Rewrite Plugin の記事では触れるだけだったオレオレrewriteプラグインを書いてみました。君のクエリにレボ☆リューション! (仮) どういう動作をさせるかというと、 mysql57> SELECT 1; +---+ | 1 |
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました