REPLACE INTOが実はINSERT +
DELETEだった(INSERTが先で後から消す)の続き。
REPLACE INTOは「DELETE +
INSERT(その行を消してからもう一度書く)」だと今まで思っていたけれど、
実は「INSERT + DELETE(行を突っ込んでから古い行を消す)」な動きっぽいというはなし。
そっちが先なんだびっくりー、という感じで書いたのですが、
色々手落ちがあったので後から調べたことをメモ。
1)
その結果だと時間が一緒だから、「DELETEトリガーがINSERTトリガーより先」というのは断言できない。順番は必ずしも保証されないから。
⇒TRIGGERの中身をSYSDATE(6)に書き換えてみました。
mysql56> …[さらに読む]
「INSERT .. ON DUPLICATE KEY UPDATE
..でクエリを投げているけど、99%くらいはUPDATEになっている」
「UPDATEを直接投げた方が速かったりする？」
「極端にパフォーマンス違うんだったら、UPDATEが転けてからINSERTする方式も考える」
とか聞かれたのでINSERT .. ON DUPLICATE KEY UPDATEについて調べてたんですが、
ソース読んでたら豆知識に出会ったのでメモ。
5.6.10のsql/sql_insert.ccの中でゴニョゴニョしている気配があるけど、write_record関数の中で
table->file->ha_write_row(table->record[0]してみる。
⇒何もないINSERTだとエラーになったらエラー。
⇒REPLACE INTO, INSERT .. ON DUPLICATE KEY UPDATEだと
それぞれHA_ERR_FOUND_DUPP_KEYを引っ掛けてハンドルしている。
…
Percona Toolkitのひとつpt-duplicate-key-checker。
名前の通り、重複したインデックスをチェックしてくれる。
$ pt-duplicate-key-checker
S=/usr/mysql/5.5.30/data/mysql.sock,u=tpcc,p=xxxx
--database=tpcc
#
########################################################################
# tpcc.stock
#
########################################################################
# s_w_id is a left-prefix of PRIMARY
# Key definitions:
# KEY `s_w_id` (`s_w_id`),
# PRIMARY KEY (`s_w_id`,`s_i_id`),
# Column types:
# `s_w_id` smallint(6) not null
# `s_i_id` int(11) not null
# To remove this duplicate index, execute:
ALTER TABLE `tpcc`.`stock` DROP INDEX `s_w_id`;
…
この記事は、おっさんの自分語りと昔話なので、あまり読む価値はないです。
もう１ヶ月くらい前になるのですが、OSS貢献者賞を頂きました。
最近はあまりOSSに貢献するようなことをしてる自覚はなかったので、なぜ自分が候補にあがったのか謎でした。OSS貢献者賞のページによると、
影響力のある開発プロジェクトを創造、運営した開発者やグローバルプロジェクトにおいて活躍する卓越した開発者及び普及に貢献した方を表彰するもの
…
[さらに読む]情報スキーマ(INFORMATION SCHEMA)はバージョン毎にテーブルが追加されていっています。 首記のバージョンで追加されたのは、次のものです。
[追加された3個のテーブル] +---------------------------------------+ | Tables_in_information_schema | +---------------------------------------+ | INNODB_BUFFER_PAGE_LRU |独自: InnoDBバッファプールページLRU情報 | INNODB_BUFFER_POOL_STATS |独自: show engine innodb status;相当の情報 | INNODB_BUFFER_PAGE |独自: InnoDBバッファプールページ情報 +---------------------------------------+ 40 rows in set (0.00 sec)
これらはまず5.6に実装されてバックポートされたものです。
5.6ではさらに20個(I_S総数でMySQL 5.5では40個、MySQL 5.6では60個)のテーブルがありますので、 …
[さらに読む]
バイナリログやスローログを遡って更新履歴をチェックしたりする時に(個人的に)面倒なのが、
`こいつらはSQLステートメントの改行を反映するし、インデントもしっかり記録してくれる'こと。
grep -v "INSERT INTO t1"とかやっても、"VALUES"の手前で改行してインデントするような
小綺麗に書かれたコードだと上手く引っ掛けにくい。
個人的にはインデントあった方が好きだけど、大量のログを見る時には不向き。
なので1分で考えたワンライナー。
perl -e '$/="#"; while(<>) { s/[ \n\r\t]{2,}/ /g; print
$_;}' | egrep -iv '^SET
(TIMESTAMP|.+session\.|INSERT_ID)|^/\*|^BEGIN|^COMMIT|^DELIMITER'
| grep '^[^#]' -B1
…
超久々となる「日本MySQLユーザ会会」が開催されました。今回は飲食付きのアレではなく、お話を聞く系の形式です。
http://atnd.org/events/37387
記憶だけで記録を書いてみる。
平塚さんの、MySQL5.6を速くするトライのお話
Oracle ACE になった平塚さんの話で会はスタート。「日本人としては
18人目のOracle ACE。18なので真のエース！」というのは、我ながら気に入ったネタｗ。
…
MySQLはデフォルトでdatadirの下にあるディレクトリはデータベースとして扱うが、
MySQL 5.6で追加された--ignore-db-dirオプションを使うと、データベースとして認識されなくなる。
これでdatadirを別パーティションに切っている時の`#mysql50#lost+found'ともさよならなのだ。
mysql> SHOW DATABASES;
+---------------------+
| Database |
+---------------------+
| information_schema |
| d1
|
| d2
|
| logs
|
| #mysql50#lost+found |
| mysql |
| performance_schema |
| test …
my.cnfには[group]というオプショングループが書けて、グループ毎に設定ができます。
オプショングループには特殊な[client]というのがあります。
[client]オプショングループは、すべてのクライアントプログラム(mysqldは除く）によって解読されます。これによって全てのクライアントに当てはまるオプションを指定することが可能になります。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.2.6 オプションファイルの使用
なので[client]にdefault-character-set =
utf8と書いておけば、(my.cnfを解釈する)全てのクライアントにdefault-character-setをセットすることが可能です。
…
[さらに読む]
MySQL5.6のmysql_install_dbは大幅に変更が加えられていて、
権限データベースを作るついでに、basedirにすごく役に立たないmy.cnfを作ってくれる。
⇒ MySQL5.6.8でrpmインストール時に変更になったこと
5.6.10だとscripts/mysql_install_dbの427～450行あたり。
このbasedir/my.cnf、ほとんどコメントアウトされていてホント何の役にも立たない上に、
sql_modeだけ指定されている。
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
さて問題です。
/etc/my.cnfにsql_modeを指定していて(たとえばPIPES_AS_CONCAT）、
このbasedir/my.cnfを削除しなかった場合。。。
上 書 き さ れ ま す 。
⇒ …