flexAsynchによるMySQL Clusterベンチマーク

MySQL Benchmark Tool
https://dev.mysql.com/downloads/benchmarks.html
―概要―
FlexAsynch is a benchmark specifically developed to test scalability of MySQL Cluster.
It is found in any MySQL Cluster source tarball under storage/ndb/test/ndbapi. The features required to
run it in this parallel manner requires a MySQL Cluster 7.x version released after the 15th of October 2011.
The DBT2 Benchmark Tool can be used to run distributed tests with many MySQL Cluster Data nodes and many
flexAsynch benchmark programs in a completely automated fashion.

Mikaelさんが、MySQL Clusterでのベンチマーク方法についての手法を書かれているので、
…

首先，StartBBS 是一款优雅、开源、轻量社区系统，基于MVC架构，采用PHP+MySQL 官网：     […]

MySQL 5.6 リファレンスマニュアル

というわけで、日本語版のマニュアルがリリースされた。これまでMySQL 5.6のリファレンスマニュアルは英語版しか無かったのだけど、公式に日本語版がリリースされる運びとなったので、是非参照して頂きたい。

かつてMySQL 5.1の日本語版マニュアルが存在したのだが、そちらは現在ウェブから参照できなくなっている。（PDF版はダウンロードできるという話も。）MySQL 5.1の日本語版マニュアルは、ぶっちゃけ翻訳があまりイケてなかったので、今後はぜひMySQL 5.6の日本語版を参照してもらいたい。ついでにもう古のバージョンは窓から投げ捨てて、この機会に是非新しいバージョンへ移行してみてはいかがだろうか。

…

恥ずかしながら完全に誤解してた。

MySQL :: MySQL 5.6 Reference Manual :: 5.1.7 Server SQL Modes

For nontransactional tables, the behavior is the same for either mode if the bad value occurs in the first row to be inserted or updated: The statement is aborted and the table remains unchanged. If the statement inserts or modifies multiple rows and the bad value occurs in the second or later row, the result depends on which strict mode is enabled:

For STRICT_ALL_TABLES, MySQL returns an error and ignores the rest of the rows. However, because the earlier rows have been inserted or updated, the result is a partial update. To avoid this, use single-row statements, which can be aborted without changing the table.

For STRICT_TRANS_TABLES, MySQL converts an invalid value to …

日々の覚書: MySQL 5.7.6でCREATE USERせずにGRANTステートメントを叩くとワーニング で、結局どうすればいいのか全く書いてなかったので書き直し。

* パスワード未設定のユーザーをGRANTで作成できなくなった。
* CREATE USERでユーザー作ってからGRANTする。

mysql57> GRANT ALL ON db.* TO grant_style@localhost; -- ユーザー未作成, パスワード未指定のGRANTが転ける
ERROR 1133 (42000): Can't find any matching row in the user table

mysql57> CREATE USER create_style@localhost; -- パスワード未指定のCREATE USERは通る
Query OK, 0 rows affected (0.00 sec)

mysql57> GRANT ALL ON db.* TO create_style@localhost; -- ユーザーが存在するとGRANTが通る
Query OK, 0 rows affected …

主にバグの再現確認に使う用途。yumでもいいからクリーンな状態のCentOS 6.6にMySQL 5.7を入れたいときの。

TL;DR

コマンドはこれ。

$ sudo yum install -y https://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
$ sudo yum install -y --enablerepo=mysql57-community-dmr mysql-community-server
$ sudo service mysqld start
$ sudo grep password /var/log/mysqld.log
$ mysql -uroot -p

1. MySQL :: Download MySQL Yum Repository からCentOS 6.x用(いや、本当はRHEL/Oracle Linux用のだけど)のrpmパッケージをインストールする（と、2015/06/01現在では↓の5つのリポジトリーが登録される）

| repository                 | enabled |
…

前の記事では、ひとつのテーブルに対する様々なクエリを対象にして、インデックスのデザイン方法について議論しました。この記事ではより実世界に即した問題解決の例として、よく似ているにも関わらず、ひとつは適したインデックスを使い、もうひとつはフルテーブルスキャンをしてしまうという、2つのクエリを取り上げます。動作の違いはバグなのでしょうか？それとも想定された動きなのでしょうか？続きを読んでみてください！

対象のクエリ2つ

# Q1
mysql> explain select col1, col2 from t where ts >= '2015-04-30 00:00:00';
+----+-------------+-------+-------+---------------+--------+---------+------+---------+-------------+
| id | select_type | table | type  | possible_keys | key    | key_len | ref  | rows    | Extra …

複数バージョンのGroonga / Mroongaで挙動の違いを調べる時に、いちいち/usr/local/mysqlを複数作るのが面倒なので手順をメモ。

コマンドの羅列はここ。 https://gist.github.com/yoku0825/a85643cd9b5a4dcd8e1c

mysqldにINSTALL PLUGINする場合、SONAMEで指定されたファイルをplugin_dirから読み出すので、plugin_dir(暗黙のデフォルトはbasedir/lib/plugin)  だけを打ち分けてやればOKなはず。

$ wget http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.24-linux-glibc2.5-x86_64.tar.gz
$ tar xzf …

たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。

おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition …

特定のSQL処理で、GROUP BYなどの集合関数を利用していて、
“Using temporary”,”Using filesort”などが出て処理時間がかかり過ぎたり、
サブクエリーによる結果をJOINしてindexが利用出来無かったりと、
困難な場面に遭遇する事があるかと思います。

基本的には、物理的に変更しても良くて数倍だと思いますので、
アプリケーションやクエリーを工数かけて書き換えて対応するのが良いと思いますが、
なかなか出来ない場合は、可能な範囲でサーバーパラメータを変更したり、
クエリーを若干変更してメモリーテーブルやTEMPORARY TABLEなどでワークテーブルを作成し、
サブクエリーなどの結果を随時集計しIndexを使えるように処理する方法もあるかと思います。
…