MySQLをコマンドで操作する - 早くなんとかしないと…

先週からスマートフォンアプリ案件のテストやドキュメント作成をしています。ず～っとWebアプリ案件に携わってきたので新鮮な気持ちです。
そこで、DBには保存してるけどアプリ側では見る術がなく、テストで確認しないといけない都合上、MySQLのDBをコマンド操作しているため、コマンドの備忘録です。

MySQL :: MySQL 5.6 リファレンスマニュアル
↑日本語リファレンスマニュアル最新？

接続・切断

MySQL :: MySQL 5.6 リファレンスマニュアル :: 3.1 サーバーへの接続とサーバーからの切断

接続

$ mysql -D database -u user -p

※"D"は大文字

Enter password:

上記のように表示されたら、パスワードを入力する。
以下のように表示されたらOK

mysql>

切断

mysql> QUIT

以下のように表示されたらOK

Bye

SELECTの可読性を上げる

mysql> select * from table1;
+----+-----------+
| id | deleteflg |
+----+-----------+
|  1 | 1         |
|  2 | 1         |
+----+-----------+

このくらいだったらまだ分かるけど、カラムが多いと表示が崩れて可読性が下がる。
そんな時は";"の代わりに"\G"。

mysql> select * from table1\G
*************************** 1. row ***************************
       id: 1
deleteflg: 1
*************************** 2. row ***************************
       id: 2
deleteflg: 1

『mysql select 整形』でググってたどり着きました↓
ちょっと変えるだけでMySQLの検索結果が格段に見やすくなる方法 | アイビースター

テーブルに関する情報の取得

MySQL :: MySQL 5.6 リファレンスマニュアル :: 3.4 データベースとテーブルに関する情報の取得

データベースのテーブル名リスト取得

mysql> SHOW TABLES;
+----------------------------------+
| Tables_in_database               |
+----------------------------------+
| table1                           |
| table2                           |
+----------------------------------+
2 rows in set (0.01 sec)

テーブル情報取得

mysql> DESCRIBE table1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| deleteflg | char(1)     | NO   |     | 0       |                |
+-----------+-------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

インデックス情報取得

これは前にWebアプリ案件でOracleのSQLチューニング(インデックスとかヒント句とか)を依頼されたけど、知識のなさと試せる環境になかった(定義のドキュメントしかなかった)のとで、後から大幅修正されてたことが悔しくて、チューニング周りをいつかちゃんと習得したくて書きました。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.5.23 SHOW INDEX 構文

mysql> SHOW INDEX FROM table1;
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| table1 |          0 | PRIMARY  |            1 | id          | A         |          24 |     NULL | NULL   |      | BTREE      |         |               |
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
1 rows in set (0.00 sec)

それにしてもdeleteflg="1"のレコードがinsertされてることを不思議に思って、製造者に確認したら、これどうも"予約"らしい。
"deleteflg"より"state"の方がいいのでは？とも思ったし、開始日時・終了日時登録されてるからこのカラムそのものもいらないのでは？と思った。(上記の例で出したテーブルはもっとカラムあるけど、ブログ用に省略してある)
まあ確かにこちらのお客様の別アプリ案件でもそんなDB設計だった覚えはあるけど、まさかそれが引き継がれているとは…と悲しい気持ちになった。
DB設計も勉強したいことのひとつではある。勉強したいことは多いのだが、最近どうもメンタルが弱って何もできていない。まずは早く心身ともに元気になりたい…