2013年4月17日にオラクルで開催された「MySQL
Casual Talks Vol.4」に初参加してきました。
さらにライトニングトーク（LT）もさせて頂けましたのでレポートしたいと思います。
前夜
開催前日の夜に「MySQL Casual Talks Vol.4」のイベント告知をTwitterで見つけました。
この手の勉強会は気づいたときには満席で参加を諦める事が多かったのですが、
今回は「事前登録不要/先着順受付」という新しい試みのお陰もあり、参加することが出来ました。
…
[さらに読む]
皆さん、Planet
MySQL Japanというサイトをご存じでしょうか？
公式のFAQ（以下参照）にあるように、MySQLにまつわる記事をまとめてくれるサービスです。
さらに、記事は https://twitter.com/planetmysql_jp にも掲載されます。
2013年4月20日現在、24のブログが登録されています。
What is Planet MySQL?
Planet MySQL is an aggregation of blogs and news from MySQL developers and users. The views expressed here are those of the author and do not …
[さらに読む]
取り敢えずBugsにも上げたんですけど、エスパーさんでないと伝わらない気がしています。
http://bugs.mysql.com/bug.php?id=68981
MySQL 5.6.2, 5.5.28,
5.1.66に搭載された新しいinformation_schema、INNODB_BUFFER_PAGEとINNODB_BUFFER_PAGE_LRU。
⇒ http://yoku0825.blogspot.jp/2013/02/informationschemainnodbbufferpage.html
これの中身をちょこちょこ確認していたところ、どうにも`ACCESS_TIME`が納得のいく値にならないことに気付いた。
mysql56> DESC INNODB_BUFFER_PAGE;[さらに読む]
+---------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | …
--master-dataのオプションの説明にこんなことが書いてある。
on servers before MariaDB 5.3 this will still take a global read
lock for a short time at the beginning of the dump;
MariaDB 5.3以降だとFLUSH TABLE WITH READ LOCKしないのか？
⇒しない。START TRANSACTION WITH CONSISTENT SNAPSHOTの時に
binlog_snapshot_fileセッション変数とbinlog_snapshot_positionセッション変数に
値を自動的に格納してくれる。すご。
https://kb.askmonty.org/en/enhancements-for-start-transaction-with-consistent-snapshot/
⇒対応していないバージョンの場合、オプション解析中にFLUSH TABLES WITH READ LOCKが
必要な分岐に流れる。
527c531,532
< …
MySQL で「Illegal mix of collations」というエラーが出ることがあります。テーブルの charset と接続の charset 等、すべてを utf8 などで統一してれば出ないので、あまり見ることはないかもしれません。
私はカラム毎に charset を指定することがあるので、時々このエラーにハマります。
たとえば、次のようなテーブルを作ったりします。
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, email VARCHAR(320) CHARSET ascii UNIQUE, name VARCHAR(30) CHARSET utf8 );
メールアドレスの規約は、ローカル部が最大64バイト、ドメイン部が最大255バイト、それと @
の1バイトで合計最大320バイトなので、 VARCHAR(320) にします。UNIQUE
インデックス持つカラムを utf8 charset で …
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貢献者賞のページによると、
影響力のある開発プロジェクトを創造、運営した開発者やグローバルプロジェクトにおいて活躍する卓越した開発者及び普及に貢献した方を表彰するもの
…
[さらに読む]