第7回 SD輪読会参加

第7回Software Design (2020年2月号、2020年3月号)輪読会 に参加してきました。

softwaredesign.connpass.com


今まで Facebookでこっそりメモを残していたけど、折角なのでなるべくオモテにも書くようにしてみようと思います。


今回のキーワード(一部):
・Electron:デスクトップアプリを作れるもの(GitHub開発)→Python なら Tcl/Tk のがあるからそれで(tkinter?)
・Btrfs:ファイルシステムの連載、すごい。絶対書籍にしてほしい
・2月号のPython連載大人気。みんな気になっているPython
・平林さんの連載は、毎回すごいね。発想からデータの取り方から扱いかたまで
・そこから派生して、しばしMIDI談義w(MIDI2.0!!)
・天神野基線(鳥取県)。基線にそってまっすぐな道があるとのこと:行ってみたくなったじゃないですか!
・通巻と発刊って何? 3月号は 通巻419号、発刊353号
・GPDにUbuntu
VSCodeのビルド環境:マックだったのね。
・シェル芸人:毎号楽しみにしているのですが「あとで試してみよう」と思いながら試さないことが多くて、反省。試したい。

私の印象と記憶に残った範囲なので(現場でメモを取っていたわけではない)、私がぼーっとしていたりまったく興味がなかったりしているもので、上記以外で話題になっていたものもあったかと思います。

 輪読会と名打っていますが、あんまり輪読っぽくなくて、SDの記事を話題の発端として、どこまで脱線できるかを競う会のような感じ(というとちょっと言い過ぎですが(笑))。 参加者の方々の知識の 深さ、長さ、広さに毎度唸らされています。 ひとりで読んでいたら絶対に興味を持たずにスルーしてしまったキーワードも、この場で話題になると「そんなすごいものだったのか」「そういうことだったのか」と発見に繋がります。

 さすがにこれは「輪読」じゃぁなかろうという声も出ていて、もしかしたら名前変えるかもしれないとのことでした。私もそれに賛成。 「SDを肴に茶話する会」みたいな感じですかね。主催者さんの発想力に期待:-)

今回もありがとうございました。

(メモ)Ubuntu 18.04 にMySQLを初めてインストール

普段は CentOS を使っているのですが(と言っても、使っていると胸張れる程は使っていない)、今回はじめて UbuntuMySQL をインストールしたので、メモ。 もしかしたら不要な操作が含まれているかもしれないけど、

OS: Ubuntu 18.04 amd 64
環境: さくらインターネットVPS の一番やすいプランで、ボタンぽちっでインストール

インストールしたいMySQLバージョンは、当然 8.0 です。何も考えずに apt-get install すると 5.7 が入ってしまうので、リポジトリ情報を変更(?)する必要があります。

$ sudo apt-get update
$ sudo apt install gpg gnupg -y

https://dev.mysql.com/downloads/ の "MySQL APT Repository" から辿って以下のパッケージのURLを得てから続行。

$ wget https://dev.mysql.com/get/mysql-apt-config_0.8.14-1_all.deb
$ sudo dpkg -i mysql-apt-config_0.8.14-1_all.deb 
$ sudo apt-get update 
$ sudo apt-get install mysql-server


 たどり着いてしまえば当然の操作の積み重ねでシンプルだったのですが、マニュアル見ながら進めていったら、どんどん別のリンクに飛ばされて、妙な深みにはまってしまいました。 とりあえず今後 ubuntu を(使い続けるかわからないけど)使うときは、このメモに帰ってこよう。


やっぱりこういうときに、ワンタッチでOSをサラの状態に戻せる環境って、便利ですね~。
今回、7~8回くらい、OSがサラの状態から試しました(笑)

MySQL Casual Talks #13 に参加してきました

MySQL Casual Talks #13 に参加してきました。
ただ聞きに行くだけのつもりでしたが、発表枠が開いているようだったので、前日だったかな、急遽発表枠に入れていただきました。ありがとうございます。
connpassで、改めて発表枠に申込しなおそうと、一般参加枠の申込をキャンセルしたら、すでに参加受付締め切り期間を過ぎていたために発表枠に申し込めない、というトラブルがあり、あせりました(笑 )。

 私の発表資料は、これ。


 ユーザ会20周年イベントの案内と発表募集、SoftwareDesign誌への連載のお話と、MySQLshapefileを取り込むお話をつめこみました。ちょっと(?)時間オーバしちゃってすいません。





発表されたみなさんとも、資料は事前または終了後すみやかに公開されていて、翌日にはすべての発表者の資料が公開されている素晴らしいスピード感でした。実は私は、当日夜には、「疲れたので明日でいいか・・・」と一瞬悪魔のささやきを受けたのですが、「いや、今晩公開すべきだ!」と少し頑張ったので、結果として足並みが揃い、頑張ってよかったです(笑)。


今回はツイート(ハッシュタグ #mysqlcasual)を追いかけていると「○○さんはすごい人」のオンパレードで面白かったですね:-)

OSC2020-Osakaに行ってきました

オープンソースカンファレンス2020大阪(OSC2020-Osaka)に行ってきました。

・・・と書くと、普段は MySQLユーザ会としてブースを出したり、セミナーをやったりしてきました!という意味だったのですが、今回は申込期間中に参加可否が決められずに、出展をしていなかったため、珍しく、一参加者としての参加です。

www.ospn.jp



 普段から気楽には参加していますが、自分のブースがないとなると、事前の準備等が一切不要なのでもっと気楽です。
少しセミナーを聞き、ブースを回っておしゃべりして、会いたかった人と話したかった話をして(やはり対面でお話すると話が早いので助かる)、おいしいラーメンを食べました。MySQLセミナーの前の枠(同じ部屋)ということもあって、OpenStreetMap Japanのお話も聞かせていただいたのですが、技術面よりも姿勢の面で非常に良い話が聞けてよかったです。 曰く、「OSMは "多様化" を目指している。 商用の地図サービスが悪いわけではない。でもそこには企業の意図が入るので、そうではないものを我々で作っていきたいということ」。 オープンソースの活動をしていると、中には「OSSこそ正義。商用製品は悪!」という姿勢で語りたがる人に出会うことがあります。自身が入れ込んだものを強く推したい気持ちはわからないでもないですが、聞いている側としては、「あぁ視野(または見えている世界)が狭い人なんだなぁ」としか思わず、非常に残念なことです。そんな中で、(肯定もしないけど)否定もしない、OSMさんのお話は、とても心地よかったです。あとでブースでお話伺おうと思っていたら、ブース出展はされていなかったようで。

 今回は、いわゆる「大回り切符」で大阪に行って、、というか寄ってきました。東京都区内発着なので「東京都区内→東京都区内」という券面になりますが、えきねっとで買うときには「東京駅から上野駅まで」として買いました。山科、金沢経由で。大阪はちょっと途中下車してはみ出したおでかけ、という感じです。ちょうど今、(かなり久々に)趣味で書いているプログラムがあって、その移動時間(2.5h+2.5h+2.5h)のほとんどをコード書きに使いました。なかなか、こんなまとまった時間を確保できることはないので、ずいぶん捗り、この点でも大阪に行ってよかったなぁと思いました(高コストな時間確保術(笑))。


 今年は少し、距離を動き回ろうかと思っているので、OSC/FOSS4Gはもちろん、その他おもしろそうなイベント/カンファレンス/会合をウォッチしていきたいと思います。よさげなのがあれば紹介くださいませ。

f:id:sakaik:20200125054016j:plain

MySQL8.0.19で加わった VALUES を試してみる

MySQL 8.0.19。MySQL 8.0 の「メンテナンスリリース」です。
8.0.19より前のMySQLには、「標準SQLのひとつであるVALUES文が実装されていない」という重大な不具合が含まれていたため、バグ修正として本リリースに含まれたようです(真に受ける人がいると困るので、無粋ながら説明しておくと、これ、思いっきり「新機能」ですからね! )

 まだあまりよくわかっていないのですが、個人的にはこれは、「テンポラリテーブルを作らなくても、複数の行のデータを作れる」というものなのかなと理解しています。いまのところ。
 これまでは、クエリの中で何かの当て込み用に複数行のデータが欲しかった場合には

SELECT 13, "name1"
UNION
SELECT 17, "name2"
UNION
SELECT 19, "name3"

 のようにする方法はありました。全然スマートじゃないので、あんまり使うもんじゃないなというのが私の感想(でも、ここぞという時に役に立ったテクニックではあります)。

 VALUESは、 これを

VALUES 
    ROW(13, "name1"),
    ROW(17, "name2"),
    ROW(19, "name3")

 のように書けるもの。


 ということで、以前、緯度や経度1度あたりの長さを求める日記を書いたのですが、それを書き直してみたいと思います。今回は1度ではなく1秒の距離を求めてみることにします。

経度1秒の長さ

SELECT  ido, 
    ST_Distance( 
       ST_GeomFromText(CONCAT("POINT(", ido, " ", 135, ")"), 6668), 
       ST_GeomFromText(CONCAT("POINT(", ido, " ", 135+(1/60/60), ")"), 6668)
  ) dist
FROM (VALUES ROW(10),ROW(20),ROW(30),ROW(40),ROW(50),ROW(60),ROW(70),ROW(80),ROW(89),ROW(35),ROW(0)) as t(ido) 
ORDER BY ido;

結果:

+-----+--------------------+
| ido | dist               |
+-----+--------------------+
|   0 | 30.922293347363215 |
|  10 |  30.45543707038192 |
|  20 | 29.068816191795264 |
|  30 | 26.801938223437794 |
|  35 | 25.357920979131784 |
|  40 | 23.720694278317538 |
|  50 |  19.91554019501125 |
|  60 | 15.500025396953356 |
|  70 | 10.607016183528014 |
|  80 |  5.387103340492138 |
|  89 | 0.5478026839370822 |
+-----+--------------------+
11 rows in set (0.00 sec)

 赤道付近で約30m、北緯35度付近で 25m強となっていることが見て取れます。
 テキストエディタでINSERT文を作ったり、作業のためだけにテーブルを作ったりする方法よりもずっとスマートですね。 ST_GeomFromText()に渡すWKTを、CONCATで作っているところがちょっと格好悪いけど。

緯度1秒の長さ

 同様に、緯度1秒の長さを求めてみます。

SELECT 
  ido, 
  ST_Distance( 
     ST_GeomFromText(CONCAT("POINT(", ido,         " 135)"), 6668), 
     ST_GeomFromText(CONCAT("POINT(", ido+1/60/60, " 135)"), 6668)
  ) dist
FROM (VALUES ROW(10),ROW(20),ROW(30),ROW(40),ROW(50),ROW(60),ROW(70),ROW(80),ROW(89),ROW(35),ROW(0)) as t(ido) 
ORDER BY ido;
+-----+--------------------+
| ido | dist               |
+-----+--------------------+
|   0 |  30.71497472832411 |
|  10 | 30.724353692261502 |
|  20 |  30.75135882757604 |
|  30 | 30.792732916306704 |
|  35 | 30.817301218397915 |
|  40 | 30.843485630117357 |
|  50 | 30.897495447658002 |
|  60 | 30.948247983120382 |
|  70 | 30.989621736109257 |
|  80 | 31.016626415774226 |
|  89 |  31.02591015584767 |
+-----+--------------------+
11 rows in set (0.00 sec)

 以前の日記で書いたとおり、極付近に近づくほど、緯度1秒の長さが長くなっていることが見て取れます。

2桁の数字を作る

 確かセルコさんあたりが本に書いていた気がするのですが、クエリの中で2桁の整数が欲しくなったときのちょっとしたテクニック。 0~9の数字10件だけを登録しておいたテーブルを使う例だったと記憶していますが、VALUES文を使うと、それを、テーブルを使わずにできるようになります。

WITH t AS (
 SELECT * FROM (VALUES ROW(1),ROW(2),ROW(3),ROW(4),ROW(5),ROW(6),ROW(7),ROW(8),ROW(9),ROW(0)) AS t(n)
)
SELECT CONCAT(t1.n, t2.n) num
  FROM t t1, t t2
 ORDER BY num;
+------+
| num  |
+------+
| 00   |
| 01   |
| 02   |
:  :   :
| 98   |
| 99   |
+------+

 今まで使ってきたSQLの感覚に馴染むように、上のように書いてみましたが、実は VALUES 文は「文」ですから、これ自体が値を返すのです。
たとえば、冒頭で UNION との比較で紹介した例の実行結果は、こう。

mysql> VALUES 
    ->     ROW(13, "name1"),
    ->     ROW(17, "name2"),
    ->     ROW(19, "name3")
    -> ;
+----------+----------+
| column_0 | column_1 |
+----------+----------+
|       13 | name1    |
|       17 | name2    |
|       19 | name3    |
+----------+----------+
3 rows in set (0.00 sec)

 ということで、先ほどのCTEの中身から、余計な SELECT 文を取り去ってしまいましょう。ほら、こんなふうに書けるんです。

WITH t(n) AS (
 VALUES ROW(1),ROW(2),ROW(3),ROW(4),ROW(5),ROW(6),ROW(7),ROW(8),ROW(9),ROW(0)
)
SELECT CONCAT(t1.n, t2.n) num
  FROM t t1, t t2
 ORDER BY num;

感想

 「テンポラリのテーブルを作らずに行を生やす」ということに漠然と憧れがあったのですが、まさか本当に実装されるとは思いませんでした。そもそもこれが標準SQLだというのも知りませんでした。 ただ、これはうまく使わないと、クエリが見えにくくなってしまうかもしれないなぁ、とも感じました。いくらでも「わかりにくいクエリ」を作ることができそうです。
 また、いちいち「ROW」と書かなきゃいけないのも、ちょっと面倒に感じました。
木村明治さんが2019年夏にRDBMSごとのSQLの比較を発表してくれていましたが、その資料の21ページ以降で VALUES 文が紹介されていました。 さすがです!!! しかも、アイデア自体はMySQL発祥(マルチプルインサート時のVALUES)らしい。へぇぇ。

www.slideshare.net

MySQLのSRID()でSRID変換する際にaxis-orderで悩んだ話

訳あって、MySQLで「GEOMETRY型のカラムに、いったん SRID=0で登録したあと、一気に正しいSRIDに変換する」ということをやろうとしたところ、思惑通りにいかず随分悩んだので、整理しておきます。

やろうとしたこととエラー発生

 ここではシンプルな例に置き換えた再現実験で紹介します。

 まず、GEOMETRY型を入れられるテーブルを作りデータを1件登録します。

CREATE TABLE g1 (g GEOMETRY);
INSERT INTO  g1 VALUES (ST_GeomFromText("POINT(35 135)"));

 SRIDを指定していないので、SRID=0で登録されています。axis-orderは lat-long です(というか、そうなっていることを期待して登録しました)。登録された内容を確認してみます。

mysql> SELECT st_astext(g), st_srid(g) from g1;
+---------------+------------+
| st_astext(g)  | st_srid(g) |
+---------------+------------+
| POINT(35 135) |          0 |
+---------------+------------+

 SRID=0 で、POINT(35 135) が期待通り登録されていることが確認できました。
では、このSELECT句にもうひとつ、SRIDを6668(JGD2011)に変換したものを取得するよう、加えてみます。

mysql> SELECT ST_AsText(g), ST_SRID(g), ST_AsText(ST_SRID(g, 6668)) FROM g1;
ERROR 3732 (22S03): A parameter of function st_srid contains a geometry with latitude 135.000000, which is out of range. It must be within [-90.000000, 90.000000].

 あら。変換できません。latitudeが 135だと言われています。これは何かaxis-orderについて、認識の相違がありそうです。文字通り、方向性の違い。バンド解散の危機です。

ST_SPATIAL_REFERENCE_SYSTEMSでの定義は?

 各SRIDごとの axis-order は INFORMATION_SCHEMA の ST_SPATIAL_REFERENCE_SYSTEMS に書かれていることがあります。ということで、とりあえず SRID=0 の axis-order がどうなっているかを確認してみることにします。

mysql> select * FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID=0;                                             
+----------+--------+--------------+--------------------------+------------+-------------+
| SRS_NAME | SRS_ID | ORGANIZATION | ORGANIZATION_COORDSYS_ID | DEFINITION | DESCRIPTION |
+----------+--------+--------------+--------------------------+------------+-------------+
|          |      0 | NULL         |                     NULL |            | NULL        |
+----------+--------+--------------+--------------------------+------------+-------------+
1 row in set (0.03 sec)

 ・・・・残念。。。SRIDゼロは情報量ゼロ。

SRID=0は long-lat だと仮定して実験

 確たる情報にはたどり着けていませんが、私が latitudeだと思って登録した 135という値が、ST_SRID()関数では longitudeと解釈されたらしいことは間違いありません。latとlonを入れ替えれば動作するのではなかろうかと仮説を立てて、実験することにします。

mysql> DELETE FROM g1;
mysql> INSERT INTO  g1 VALUES (ST_GeomFromText("POINT(135 35)"));                                                               

 まぁ「丸くなった地球」を扱うために、WGS84とかJGD2011とかをずっと触ってきたMySQLユーザとしては、非常に気持ち悪いPOINTの記法ではありますが、我慢します。

先ほどエラーになったSQLを再度投げてみましょう。

mysql> select st_astext(g), st_srid(g), st_astext(st_srid(g, 6668)) from g1;                                                
+---------------+------------+-----------------------------+
| st_astext(g)  | st_srid(g) | st_astext(st_srid(g, 6668)) |
+---------------+------------+-----------------------------+
| POINT(135 35) |          0 | POINT(35 135)               |
+---------------+------------+-----------------------------+

 動きました! しかも、元のSRID=0の時の値が 135-35 だったのに、SRID変更*1したら 35-135 に変わったのも驚きです。

まとめ

 昨年にも、axis-order について内部の保持方法を含めて議論があったことを記憶していますが、当時の私の経験不足でついて行ききれなかった部分がありました。今回のこの事象が、その話かどうか再確認はしていないのですが、axis-order問題、こういうところでハマるんだなぁと体感できた、大変良い年末でした(笑)。

おまけ

 やりたかったのは、こういうことでした(もう少し複雑ですが本質的にはこんな感じ)。
一旦 SRID=0 で登録して(つまりSRID不明のまま処理を開始している)、登録が終わったあとで一気にSRIDを置き換える、と。
 今回のデータ例での実行結果を以下に紹介して本エントリを終わりにいたします。

mysql> UPDATE g1 SET g=ST_SRID(g, 6668);
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select st_astext(g), st_srid(g) from g1;
+---------------+------------+
| st_astext(g)  | st_srid(g) |
+---------------+------------+
| POINT(35 135) |       6668 |
+---------------+------------+
1 row in set (0.00 sec)


 せっかくなので本日記を、今年は盛り上げきれなかった RDBMS-GIS アドベントカレンダの25日目ぶんとして登録しちゃうことにします:-) システム的に登録可能な時期でしたらいつでもみなさん、空いている日に追加エントリ登録しちゃってくださいませ。
qiita.com



追記: SRID=0については、@dupont-kedama さんの以下のエントリも参照ください。とくに、SRIDを指定しなくてSRID=0として扱われる場合と、SRID=0を指定した場合は違うんだぞ、という話が興味深かったです。
dupont.hatenablog.jp


追追記:
 SRID=0で lat-lon で登録した列に対して、ST_SRID()でのSRID変更相当の処理を行う方法を思いついた。

mysql> select st_astext(g), st_srid(g), ST_AsText(ST_GeomFromText(st_astext(g),6668))  from g1;
+---------------+------------+-----------------------------------------------+
| st_astext(g)  | st_srid(g) | ST_AsText(ST_GeomFromText(st_astext(g),6668)) |
+---------------+------------+-----------------------------------------------+
| POINT(35 135) |          0 | POINT(35 135)                                 |
+---------------+------------+-----------------------------------------------+

 うん、確かにできているけど、、、、格好悪い。。

*1:変換と変更という言葉を厳密に使い分けています。与えられた座標値の数字をそのままにSRIDだけ読み替えることをここでは「変更」と呼んでいます

MySQLのDROP DATABASEでWARNINGが表示されない事象

 DROP DATABASE IF EXISTS ... で存在しないデータベースをドロップしようとしたときに、WARNING が表示されない事象があったので紹介します。

IF EXISTS (テーブルの場合)

 MySQLDROP文には "IF EXISTS" というオプションがあり、たとえばテーブルの場合は、以下のように使います。

mysql> use test
mysql> DROP TABLE IF EXISTS mytable999;                                                                                             
Query OK, 0 rows affected, 1 warning (0.02 sec)

 mytable999 というテーブルは存在しませんが、IF EXISTS 句のおかげでエラーにはならず正常終了しています。
ワーニングがあるようなので見てみます。
 

mysql> SHOW WARNINGS;
+-------+------+---------------------------------+
| Level | Code | Message                         |
+-------+------+---------------------------------+
| Note  | 1051 | Unknown table 'test.mytable999' |
+-------+------+---------------------------------+

 そんなテーブルは存在しないよ、と言っています。
・・と、こんな感じの動作をします。

IF EXSISTS (データベースの場合)

 DROP DATABSE でも同じく IF EXISTS 句が使えるのでやってみます。

mysql> DROP DATABASE IF EXISTS test999;
Query OK, 0 rows affected, 1 warning (0.00 sec)

 test999というデータベースは存在しないので、ワーニングがでています。テーブルの時と同じように見てみましょう。

mysql> SHOW WARNINGS;                                                                                                            
Empty set (0.00 sec)

 なんと! ワーニングが表示されません!

WARNINGをすぐに表示するオプションなら表示される

 ということをtwitterに書いたら、すかさずとみたさんた実験してくれました。 mysqlコマンドラインクライアントは --show-warnings というオプションを付けて起動することで、warningが出た時にすぐにwarningメッセージを表示してくれる機能があります。(デフォルトではワーニングは「発生したという事実(と個数)」を表示するだけで、メッセージは表示されません)

 ワーニングが内部で発生していないというわけではないようです。ということは、内部的な後続処理でワーニングが消されてしまったという可能性が考えられます。

クエリが投げられていることを確認する

 STATUSの Questions で、これまでMySQLサーバに投げられたリクエストの数がわかるので、これを監視してみる方法があります。
まずテーブルのドロップで、動作を確認してみます。

mysql> SHOW STATUS LIKE '%Questions%';                                                                                           
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 42    |
+---------------+-------+

 42このクエリがこれまで投げられたということです。ここでテーブルをDROP して、再びQueriesを確認してみると、

mysql> DROP TABLE IF EXISTS mytable999;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> SHOW STATUS LIKE '%Questions%';                                                                                           
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 44    |
+---------------+-------+

 44になりました。 DROP TABLE で1クエリ、SHOW STATUS 自身で1クエリ投げているので、2だけ増えるのは納得の結果です。


 では DROP DATABASE ではどうなるか。

mysql> SHOW STATUS LIKE '%Questions%';                                                                                           
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 51    |
+---------------+-------+

mysql> DROP DATABASE IF EXISTS test999;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SHOW STATUS LIKE '%Questions%';                                                                                           
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 54    |
+---------------+-------+

 なんと、3増えました。仮説を裏付ける結果となりました。
そしてこの結果を、よりダイレクトにとみたさんが確認してくれました。私が今回さくっと試した環境は、事情があってパラメタをいじりたくなかったので試せなかったのですが、MySQLサーバオプションで一般ログを出力するようにすることで、どんなクエリが投げられたのかを確認することができます。

 ということで、DROP DATABASE のあとに 内部的に SELECT DATABASE() が投げられていることがわかりました。これにより発生したワーニングが消されてしまっているということですね。

さぁバグ報告だ! と思ったら・・・先人たちの報告

 調べてみると、すでにbugs.mysql.comへの報告が行われていました。2015年のことです。

MySQL Bugs: #79684: "drop database if exists" says "1 warning", but "show warnings" returns nothing

 同じ動作に気づいた人もいるようで、2017年、2018年にもそれぞれ同様の動作が報告されています(報告前に調べましょう)。

MySQL Bugs: #86989: Missing warning after DROP DATABASE IF EXISTS for a non-existent database
MySQL Bugs: #90058: Note for dropping a non-existent table not shown


 まぁ重要度が低いと考えられているのか、4年たっても直す気配がない様子ですね。 
こういうこともあるので、もしかしたら --show-warnings はデフォルトでオンにしておいてもいいのかなという気が、少ししてきました。これによってどれくらい、鬱陶しいメッセージが増えてしまうか、との兼ね合いなのでしょうけれど。


 なお、この実験をしている最中、どうも私が無意識に TABLE と DATABASE をよく打ち間違えていたようで、twitter上でも(おそらく間違えて打った結果を勘違いして)混乱する情報を出してしまって失礼しました。 「そんな結果にならないよ」と、すかさずツッコミを入れてくれたとみたさん、ありがとうございました!


おまけ

 この日記を書くために改めて実験していて、「そういやこのサーバ、Queriesがこんなに小さな値のわけがないんだけど・・・」と気づきました。
そうか、Queries は、GLOBALとSESSION で、それぞれ値を持っているのですね。 普段気にしないから認識の外にありましたが、副次的な学びでした(笑)。

mysql> SHOW GLOBAL STATUS LIKE 'Questions';                                                                                      
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 23324 |
+---------------+-------+

mysql> SHOW STATUS LIKE 'Questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 46    |
+---------------+-------+