[B! mysql][kazuho] kamipoのブックマーク

Kazuho at Work: Using Top N Sort on MySQL

One of the best practices on using MySQL is to avoid filesort. However there are cases where it is inevitable (e.g. ordering the result of fulltext search by modification date), and although in most cases we only the top N rows of sorted resultset are needed, MySQL does not implement top N sort. After wondering for couple of months if I should hack the MySQL core to implement top-N-sort, today I d

kamipo 2010/11/30

リンク

Kazuho@Cybozu Labs: Deployment of MySQL using daemontools, XtraBackup

I am sure many people have already done similar things, but to ease my pain of setting up mysqld on a large-scale environment (I am trying to create a set of database nodes, each node consists of a MySQL failover cluster using semi-sync replication, that can be administered easily), I have just finished writing a deployment script called mysqld_jumpstart. The caveats are: integration with daemont

kamipo 2010/05/19

リンク

Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)

一昨日に開催された hbstudy #7 にバックアップの話を聞きに行ってきました。Amanda を中心にした話で、とても勉強になりました。が、設定がめんどくさそうだなぁ、とも。自分の需要にはあわない感じでした。勉強会が終わったあとで、自作のバックアップスクリプト blockdiff に関する話を何人かの方とさせていただいたのですが、思いのほか反応が良かったので、あらためて紹介したいと思います。 blockdiff は、一言でいうと、パーティションやデータベースのデータファイルの差分バックアップツールです。rsnapshot に似ていますが、rsnapshot ではデータベースのホットバックアップ不可能です。逆に blockdiff はディレクトリ単位でのバックアップには対応していないかわり、ファイルシステムやデータベースを、一貫性を保ちつつ実質無停止で差分バックアップすることができます

kamipo 2010/01/18

リンク

Kazuho@Cybozu Labs: MySQLをロックしてほげほげするツール「mysqllock」を書いた

MySQLを使っていると書込みロックをかけてバックアップを取る、ってのは一般的だと思います。実際、標準添付の mysqlhotcopy や Xtrabackup もそういうことをやっています。しかし、これらはいずれもロックの管理とバックアップ処理が密結合になっている（ですよね？）のが玉に瑕。特にボリュームレベルのスナップショット機能を使ってバックアップを取る場合、スナップショットを取るためのコマンドは環境（LVM とか XenServer とか VMware ESXi とか...）によって異なるので、ロック管理とバックアップコマンドは疎結合にしておきたい。と思ったので、書くことにしました。というか、疎結合なのを探すより書いたほうが早かった。コードはこちら↓。使い方は、以下のとおり。setlock 風のインターフェイスなので、慣れている人には簡単だと思います。 % mysqllock

kamipo 2009/12/03

リンク

Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる

最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？　以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb

kamipo 2009/07/03

リンク

https://labs.cybozu.co.jp/blog/kazuho/archives/2007/09/mysql_param_binding.php

kamipo 2009/03/01

Perl の場合、DBI::execute を呼んでいると、プリペアードステートメントのパラメータは必ずクォートされてしまいます。集約処理等、重たいSQLを実行するにあたっては、DBI::bind_param で数値型であることを明示すべき

リンク

MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場

useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a probl em? Because users do not clean up/close unused prepared statements. Multiply the number of prep