テーブルを結合して一括削除を行う場合。

DELETE の後に、テーブルエイリアスを書く必要があるとのこと。

DELETE
    h <- これがミソ
FROM
    `hoges` AS h
LEFT JOIN `moges` AS m
    ON m.`hoge_id` = h.`id`
WHERE
    h.`id` = 5

知らなかった。。。

確かに、ミソのところがないと、構文エラーとなる。

これがエイリアスでなくて、テーブル名の直書きだったらどうなのかとか
未調査。

Qiita：mysqlでjoinした結果をdelete（2015-01-27）

GitHub：nkjmlab/nkjmlab-utils-jpdatum

あちこちの記事で、ドライバの入手先として
公式：MySQL Community Downloads　Connector/J
を挙げていたけど、どうやって DL してよいのかわからなかった。

同ページに、Recommended Windows Download: と書いてあるから
MySQL インストールディレクトリに同梱されているのかと思ったけど
エクスプローラで、mysql-connector-java で検索してみたものの、ヒットせず。

仕方がないので
Maven Repository：MySQL Connector/J　8.0.18
こちらの、Files：jar (2.2MB) から DL した。

2019-11-05 現在
mysql-connector-java-8.0.18.jar

として配置。

ビルド・パス の設定。

数多くサンプルがある中、下記が見やすかったので
不要な部分を削除して、そのままいただきました。
TASK NOTES：JavaでMySQLに接続してデータ操作をする（2015-04-14）

import java.sql.*;

public class MySQLConnector {
    public static void main(String[] args) {
        Connection con = null;
        try {
            // MySQLに接続
            con = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "");
            System.out.println("MySQLに接続できました。");
        } catch (SQLException e) {
            System.out.println("MySQLに接続できませんでした。");
        } finally {
            if (con != null) {
                try {
                    con.close();
                } catch (SQLException e) {
                    System.out.println("MySQLのクローズに失敗しました。");
                }
            }
        }
    }
}

Statement stm = con.createStatement();
String sql = "select * from programing";
ResultSet rs = stm.executeQuery(sql);

while(rs.next()){
    int id = rs.getInt("id");
    String name = rs.getString("name");
    System.out.println("取得結果 -> " + id + ":" + name);
}

Statement stm = con.createStatement();
String sql = "insert into programing values(4, 'Python'), (5, 'Go')";
int result = stm.executeUpdate(sql);
System.out.println("更新件数は" + result + "です。");

TASK NOTES：JavaでMySQLに接続してデータ操作をする（2015-04-14）
→とても見やすく、コードは、ほぼそのまま真似させていただきました。

rpm -ivh https://dev.mysql.com/get/mysql80-community-release-el7-2.noarch.rpm

noarch の前の数値が、前回の 1 から 2 へ増えている。
気になるけど、次回！

yum repolist all | grep mysql

yum install -y mysql-community-server

// 起動
systemctl start mysqld.service

// 停止
systemctl stop mysqld.service

// 自動起動
systemctl enable mysqld.service
systemctl list-unit-files -t service | grep mysqld
mysqld.service                                enabled
mysqld@.service                               disabled

cat /var/log/mysqld.log | grep "A temporary password"
2019-03-09T05:40:56.206659Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: hogehoge

mysql -uroot -p -hlocalhost
Enter password:

上記初期パスワードを入力。

今回は、my.cnf で設定しただけではダメで
下記処理が必要だった。

パスワード変更
まで面倒なことをしなくても

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'MyNewPass';

こちらでうまくいった。

use mysql;
select user, host, plugin from user;
+------------------+-----------+-----------------------+
| user             | host      | plugin                |
+------------------+-----------+-----------------------+
| mysql.infoschema | localhost | caching_sha2_password |
| mysql.session    | localhost | caching_sha2_password |
| mysql.sys        | localhost | caching_sha2_password |
| root             | localhost | mysql_native_password |
+------------------+-----------+-----------------------+
4 rows in set (0.00 sec)

タイムゾーン

my.cnf 8.0.x

Qiita：CentOS7にMySQL8.0をインストール（2019-02-17）

インストール直後に例の「初期パスワードを調べなきゃ」と思ってやり方を探していた際
Qiita：MySQL 8.0 初期設定覚書（2019-02-07）
を見つけた。

初期パスワードを調べなくてよい方法が書かれているようだったので
ロクに調べもせずに、盲従して

mysqld  --initialize-insecure
mysql_secure_installation

Securing the MySQL server deployment.

Enter password for user root:

となり、参考サイトとは異なる道順となってしまった。

あれ？と思い、

systemctl  enable  mysqld
systemctl  start   mysqld
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

と起動してみたところ、エラーとなった。

systemctl  status   mysqld
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 水 2019-02-27 00:57:05 JST; 16s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 15500 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS (code=exited, status=1/FAILURE)
  Process: 15483 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 15500 (code=exited, status=1/FAILURE)
   Status: "SERVER_BOOTING"
    Error: 2 (そのようなファイルやディレクトリはありません)

 2月 27 00:57:05 localhost.localdomain systemd[1]: Starting MySQL Server...
 2月 27 00:57:05 localhost.localdomain systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE
 2月 27 00:57:05 localhost.localdomain systemd[1]: Failed to start MySQL Server.
 2月 27 00:57:05 localhost.localdomain systemd[1]: Unit mysqld.service entered failed state.
 2月 27 00:57:05 localhost.localdomain systemd[1]: mysqld.service failed.

ちなみにこのタイミングで初期パスワードを確認してみたら

grep -i password /var/log/mysqld.log
2019-02-26T15:54:54.194358Z 5 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.

となった。

ログを確認してみたところ

vi /var/log/mysqld.log

2019-02-26T15:57:05.414331Z 1 [ERROR] [MY-012271] [InnoDB] The innodb_system data file 'ibdata1' must be writable

となっていたので

当該ファイルの場所を探し

find / -name 'ibdata1'
/var/lib/mysql/ibdata1

当該ファイルの権限を確認してみたら

ll /var/lib/mysql

ほとんどの権限者が root になっていた。

他の仮想マシンを参照したところ
全ての権限者が mysql になっていた。

あちゃー。。。

rm -rf /var/lib/mysql/*
yum remove mysql-community-server
yum install -y mysql-community-server

この時点では

ll /var/lib/mysql
合計 0

続いて

systemctl status mysqld.service
systemctl start mysqld.service

こうしたら

ll /var/lib/mysql
合計 168000
drwxr-x--- 2 mysql mysql      187  3月  9 14:41 #innodb_temp
-rw-r----- 1 mysql mysql       56  3月  9 14:40 auto.cnf
-rw-r----- 1 mysql mysql      155  3月  9 14:41 binlog.000001
-rw-r----- 1 mysql mysql       16  3月  9 14:41 binlog.index
-rw------- 1 mysql mysql     1680  3月  9 14:40 ca-key.pem
-rw-r--r-- 1 mysql mysql     1112  3月  9 14:40 ca.pem
-rw-r--r-- 1 mysql mysql     1112  3月  9 14:40 client-cert.pem
-rw------- 1 mysql mysql     1680  3月  9 14:40 client-key.pem
-rw-r----- 1 mysql mysql     5748  3月  9 14:40 ib_buffer_pool
-rw-r----- 1 mysql mysql 50331648  3月  9 14:41 ib_logfile0
-rw-r----- 1 mysql mysql 50331648  3月  9 14:40 ib_logfile1
-rw-r----- 1 mysql mysql 12582912  3月  9 14:41 ibdata1
-rw-r----- 1 mysql mysql 12582912  3月  9 14:41 ibtmp1
drwxr-x--- 2 mysql mysql      143  3月  9 14:40 mysql
-rw-r----- 1 mysql mysql 25165824  3月  9 14:41 mysql.ibd
srwxrwxrwx 1 mysql mysql        0  3月  9 14:41 mysql.sock
-rw------- 1 mysql mysql        6  3月  9 14:41 mysql.sock.lock
drwxr-x--- 2 mysql mysql     4096  3月  9 14:40 performance_schema
-rw------- 1 mysql mysql     1680  3月  9 14:40 private_key.pem
-rw-r--r-- 1 mysql mysql      452  3月  9 14:40 public_key.pem
-rw-r--r-- 1 mysql mysql     1112  3月  9 14:40 server-cert.pem
-rw------- 1 mysql mysql     1680  3月  9 14:40 server-key.pem
drwxr-x--- 2 mysql mysql       28  3月  9 14:40 sys
-rw-r----- 1 mysql mysql 10485760  3月  9 14:41 undo_001
-rw-r----- 1 mysql mysql 10485760  3月  9 14:41 undo_002

無事に権限者が mysql になった。

前回は何だったのかしらね。。。

GROUP BY を用いたら、下記エラーが出た。

Google 先生に質問すると、一杯出てきた。。。
MySQL 5.7 から仕様変更になったのが原因だそうな。

sql_mode=only_full_group_by
この部分。

my.cnf のデフォルトで sql_mode に only_full_group_by が追加されたため
GROUP BY を用いたときは、一意である値しか SELECT できなくなったとのこと。

my.cnf の sql_mode から only_full_group_by を外してしまえば、5.6 までと同じように動作するとのこと。

• GROUP BY で指定したカラム
• 集約関数を利用しているカラム
• 全て同値であるカラム（？）

これらについては、SELECT できるので
それだけを指定する。

Qiita：脱！ゆるふわMySQL（2015-12-16）

CSV からデータをロードしようとしたら

というエラーが出た。

CSV の中身を見ると、当該カラムの値は “null” となっている。

MySQL の CLI から入れようとしたら Warning が出た。

気持ち悪いので、なんとかしてみようと思った。

ちなみに対象カラムのデータ型は DATETIME。

LOAD DATA LOCAL INFILE '/path/to/csv_file.csv' INTO TABLE hoge FIELDS TERMINATED BY ',' ENCLOSED BY '"' SET deleted = nullif(deleted, '0000-00-00 00:00:00');

どこで見たか忘れてしまったけど
こういうやり方があるらしい。

以前試したときは上手くいった。

ただ今回は、複数カラムが対象で

LOAD DATA LOCAL INFILE '/path/to/csv_file.csv' INTO TABLE hoge FIELDS TERMINATED BY ',' ENCLOSED BY '"' SET registered = nullif(deleted, '0000-00-00 00:00:00'), deleted = nullif(deleted, '0000-00-00 00:00:00');

このように書いてみたけど、上手く行かなかった。

すぐ諦めたので、何が悪いのか、そもそもこの書き方が正しいのかすら不明。

null のカラムの CSV 値を “\N” とする手法。

これもどこかに書いてあったのを見かけた記憶があったので試してみたところ、
なんと、上手くいった♪

Excel のセルに \N とそのまま記述して
CSV では、”\N” となるように吐き出したところ
OK だった。

CakePHP3 を利用しているときに、下記エラーが出た。

調べてみると、MySQL のタイムゾーン設定がなされていないとのこと。

mysql データベースを見ると、確かに空っぽだった。

select * from mysql.time_zone;
Empty set (0.00 sec)

mysql_tzinfo_to_sql /usr/share/zoneinfo/ | mysql -u root mysql -p
Enter password:
Warning: Unable to load '/usr/share/zoneinfo//iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo//zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo//zone1970.tab' as time zone. Skipping it.

３つ位失敗したみたいだけど、無事にタイムゾーンが mysql データベース time zone name テーブルへ登録された♪

select * from mysql.time_zone;
+--------------+------------------+
| Time_zone_id | Use_leap_seconds |
+--------------+------------------+
|            1 | N                |
|            2 | N                |
|            3 | N                |

            __ snip __

|         1778 | Y                |
|         1779 | Y                |
|         1780 | Y                |
+--------------+------------------+
1780 rows in set (0.00 sec)

MySQL Community Downloads　Time zone description tables
から、MySQL 5.7+ 用の timezone_2019c_posix_sql.zip を DL。

上記ファイルを解凍して出てきたファイルを、C ドライブ直下へ配置して実行。

mysql -u root -p mysql < c:\timezone_posix.sql

を更新してから

show variables like '%time_zone';
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| system_time_zone |            |
| time_zone        | Asia/Tokyo |
+------------------+------------+
2 rows in set, 1 warning (0.01 sec)

有限会社 エス技研：MySQLのタイムゾーン（mysql_tzinfo_to_sql）の設定方法・XAMPP環境の解説も（2017-06-16）
→Linux 環境について、参考にさせていただきました

Pentec：MariaDB (MySQL) のタイムゾーン、タイムゾーンテーブルを設定する
→Windows 環境について、参考にさせていただきました

いつも大変お世話になっている phpMyAdmin。
この度、初めてインストール作業を行うことになりました。

公式：Bringing MySQL to the web

上記公式サイト右上の [Douwload 4.7.6] をクリックすると DL できる。

2017-12-10 現在
phpMyAdmin-4.7.6-all-languages.zip

または、ダウンロードページ から、詳細な選択をすることも可能。

DL した .zip ファイルを解凍して、任意のディレクトリへ配置。

今回は、アプリケーションディレクトリ直下へ配置した。

また、ディレクトリ名が長いので
phpMyAdmin-4.7.6-all-languages → pma とリネームした。

Cookie を有効にしておかないと、ログインできない。

必須ではない。

をコピーリネームして

を配置。

これがデフォルトの設定らしい。

今回はローカル環境なので、適当に。

$cfg['blowfish_secret'] = 'hoge'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

上記設定をしたら、pma 側で下記エラーが出だ。

現在の VirtualBox を利用した仮想環境においては
config.inc.php に、パーミッションを設定できないので
こうなるらしい。

config.inc.php を削除しました。。。

その他の config.inc.php については
ko-iya528：phpMyAdminのインストール（2017-10-26）

phpMyAdmin は、テーマの概念があり
テーマを変更することで外観を変更することができる。

テスト環境と本番環境において
取り違えによる大事故を起こさないためにも
テーマは設定しておこうね！

色々とあるのかもしれないけど
公式：Themes
で、配布しているので、こちらから頂戴する。

今回は、4.7.6 なので、4.7 の中から選択。

４種類ある中から、Metro 2.6 にした。

metro-2.6.zip というリンクから DL。

DL してきた .zip ファイルを解凍して
出てきた metro ディレクトリをそのまま

へ配置。

ホームページ
「外観の設定」
Theme：[metro] を選択

にて、Metro テーマのテーマを選択できる。（ややこしいｗ）

/* Theme color scheme
 * Values: "teal", "redmond", "blueeyes", "mono", "win"
 * Set this value for the desired color scheme
 */

$scheme                                     = "win";

に、色設定があるので、そちらをカスタマイズ。
テーマカラー

case "win":

    $GLOBALS['cfg']['NaviColor']                = '#EEEEEE';
    $GLOBALS['cfg']['NaviBackground']           = '#377796';	// ページ上部ナビゲーションバーの背景色
    $GLOBALS['cfg']['NaviBackgroundLight']      = '#428EB4';
    $GLOBALS['cfg']['NaviPointerColor']         = '#333333';
    $GLOBALS['cfg']['NaviPointerBackground']    = '#377796';
    $GLOBALS['cfg']['NaviDatabaseNameColor']    = '#333333';
    $GLOBALS['cfg']['NaviHoverBackground']      = '#428EB4';
    $GLOBALS['cfg']['MainColor']                = '#444444';
    $GLOBALS['cfg']['MainBackground']           = '#FFFFFF';
    $GLOBALS['cfg']['BrowsePointerColor']       = '#377796';
    $GLOBALS['cfg']['BrowseMarkerColor']        = '#000000';
    $GLOBALS['cfg']['BrowseWarningColor']       = '#D44A26';
    $GLOBALS['cfg']['BrowseSuccessColor']       = '#01A31C';
    $GLOBALS['cfg']['BrowseGrayColor']          = '#CCCCCC';
    $GLOBALS['cfg']['BrowseMarkerBackground']   = '#EEEEEE';
    $GLOBALS['cfg']['BorderColor']              = '#DDDDDD';
    $GLOBALS['cfg']['ButtonColor']              = '#FFFFFF';
    $GLOBALS['cfg']['ButtonBackground']         = '#377796';
    $GLOBALS['cfg']['ButtonHover']              = '#428EB4';
    $GLOBALS['cfg']['ThBackground']             = '#F7F7F7';
    $GLOBALS['cfg']['ThDisabledBackground']     = '#F3F3F3';
    $GLOBALS['cfg']['ThColor']                  = '#666666';
    $GLOBALS['cfg']['ThPointerColor']           = '#000000';
    $GLOBALS['cfg']['BgOne']                    = '#F7F7F7';
    $GLOBALS['cfg']['BgTwo']                    = '#FFFFFF';
    $GLOBALS['cfg']['BlueHeader']               = '#3A7EAD';	// 注意書きなどの背景色
    break;

とあるテーブルに CSV データを入れ込もうとして下記エラーが出た。

このエラーは外部キー制約に違反したデータを保持した状態で
当該テーブルを更新しようとすると出るとのこと。

親テーブル（table_a）の取り込み時に、２行欠落していた。

親テーブル（table_a）を取り込み直して解決。
かなすぃ。 XO

あ～、またやってしまったと思い、
あれこれデータを調べてみたけど、不整合を見つけることができなかった。

親テーブル（table_a）の ID は、1～365。
子テーブル（table_b）の table_a_id カラムに入っている値を
phpMyAdmin で検索して、1 より小さいもの、365 より大きいものを見てみたけど
検索結果は 0。

ふと気になって、table_a のデータ件数を見てみたら
なんと！ 364件。
あり？　と思って、データを追ってみたら
ID:358 がない。。。

改めて、LAOD DATA LOCAL INFILE のログを見てみたら、あらら。。。

じぇんじぇん見てなかったじぇ。。。
これを確認していれば、無駄な時間を取られずにすんだのに～。

Skipped: 2 なのに、364件あったのは。。。
い、今は気が付かなかったことにしましょ。。。

MySQL：13.2.9.2 JOIN Syntax

グループ化されたデータ（GROUP BY）に対して
検索条件を指定する。

よって、GROUP BY 句内のカラムか、または集約関数で使用されるカラムしか参照できない。

HAVING 句は、すべての GROUP BY 句のあとで、かつすべての ORDER BY 句の前にある必要があります。

MySQL：13.2.9 SELECT 構文

この記事は、日本語版 5.5用はなかった。

HAVING 句は、ほぼ最後 (項目がクライアントに送信される直前) に最適化なしで適用されます。(LIMIT は HAVING のあとに適用されます。)

MySQL：13.2.9 SELECT 構文

カラムエイリアスを使用できる。

ちょ、ちょっと私にはハードルが高い。。。と思われる。
でも、少しずつでも触っていれば、理解していけるかもしれないので
いつもの通り特攻してみるメモ。

クエリの実行内容解析？
SELECT ステートメントの頭に EXPLAIN を付けて実行する。

上のクエリ例と下の EXPLAIN 例の内容は全く合致してないけど。。。

漢のコンピュータ道：MySQLのEXPLAINを徹底解説!!（2009-03-31）
→ちょっと古い記事だけど、詳しくてわかりやすい

Qiita：MySQLのEXPLAIN（2014-10-23）
→上記記事を参考にまとめられた記事

MySQL 5.6 では、非推奨になってしまったらしい。
なくなっちゃうんだって。
GMOメディア エンジニアブログ：MySQL 5.6ではprofilingが非推奨になってしまった件

漢のコンピュータ道：プロファイリングで快適MySQLチューニング生活（2009-02-03）
→ちょっと古い記事だけど、詳しくてわかりやすい

MySQL Casual：show profileでフェーズごとの実行時間を見る – MySQL Casual Advent Calendar 2010（2010-12-05）
→PROFILE を貯める方法？　と、それを参照する方法が載っている

Qiita：誰も教えてくれなかったMySQLの障害解析方法（2014-07-12）
→まだまだサッパリわからない。というか試す暇がないけど、いつかやりたい！