20220223のMySQLに関する記事は6件です。

M1のMacにMysqlをインストールしようとしたらエラーが出た件

HomebrewでMysqlをインストールしようとしたら以下のエラーが出た。 brew install mysql curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) Error: mysql: Failed to download resource "mysql" Download failed: https://ghcr.io/v2/homebrew/core/mysql/blobs/sha256:5f6efe3a8985554faf3c5a2f74e1029971d7fbebb13922aae117cffd7bdeba58 解決策 brew install openssl 以上。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WSL2のMySQLでroot@localhostに入れない問題を解決した備忘録

症状 WSL2にMicrosoftの指示に従ってMySQLを入れると mysql -u root -p でいくらやってもrootuserでmysqlにログイン出来ない。(パスワードが使えないよぅとか言ってくる。インスコ時に入れたくね!?って思うんやけど) ただし、 sudo mysql ならば、ログインできる。 原因 とりまログインした状態で mysql> select user,host, plugin FROM mysql.user; をすると、 +------------------+-----------+-----------------------+ | user | host | plugin | +------------------+-----------+-----------------------+ | iroiro | localhost | caching_sha2_password | | root | localhost | auth_socket | +------------------+-----------+-----------------------+ みたいな表示が出てくる。で、調べたところによるとmysql-community-serverのインストール時にrootのパスワードをUNIX socketベースの認証をすることができるらしく、それをやってしまっているためにLinux側でrootユーザーならMySQLもrootユーザーという認証の仕方になってしまっている。 なので、いくら SET PASSWORD だのなんだのやっても、パスワードが変更したり出来ない。 解決方法 rootでログインした状態で以下のコマンドを実行する。 mysql>ALTER USER root@localhost IDENTIFIED WITH caching_sha2_password BY 'hogehoge'; hogehogeにはパスワードを入れる。終わり。 感想 今どきの人はみんなDocker使うから設定時点で多分パスワードとか入れるので、こんなこと起きないのかなぁと思いながら、またいつか自分が引っかかったときのために残しておくことにした。 追記 僕はNode.jsでMySQLを使うおうとして、このエラーにあたったわけだが npm install mysql でインストールされるmysqlを使うと今度はcaching_sha2_passwordがサポートされていない。 ので、 npm install mysql2 をして、mysql2を使うと良い。 参考文献
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【M1 Mac】MySQL Workbench から Sequel Ace に乗り換えただけの話【コマンドラインからのDB直接接続】

MySQLのGUI 皆さんはMySQLのGUIを使っているでしょうか? 自分は今までM1MacでMySQL Workbenchを使用していたのですが、Sequel Aceに乗り換えたところ、想像以上に軽くておすすめです。 おまけ1 -コマンドラインからのDB直接接続- open "mysql://root:root@127.0.0.1:3306/db" -a "Sequel Ace" おまけ2 -言語変更- 英語だと「Relations」となっているページが「関連」となっているのが気になる方は、 アプリ別の言語設定で英語化することができます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【MySQL】NULLの取り扱いについて

MySQLでハマった。 NULLは極力使わないほうが良いのではないかとも思っている。 一連の経験について記しておき、誰かの役に立てれば幸いです。 概要 「!=」ではNULLを拾わない。。。 どういうことか? あるカラムに、「Null」「1」「5」「10」が入っていたとしよう。 そこでこのカラムの値が1以外のものを抽出しようとする。 SELECT * FROM (テーブル名) WHERE (カラム名) != 1; これで行けると思われる。 しかし、結果として「5」「10」は抽出できるが、「Null」は抽出できない。 詳細 SELECT分を実行し、1レコードずつ見ていくとき、 WHERE (カラム名) != 1 の(カラム名)に各値が入っていく。つまり、 WHERE (カラム名) != 1  ↓ WHERE 5 != 1  ↓ true という動きとなるが、nullだった時 WHERE (カラム名) != 1  ↓ WHERE null != 1  ↓ false となる。よってSELECT文でnullが入っているレコードを抽出できない。 カウントしたいときとかに正確な数字を出すことができないので注意。 まだまだ駆け出しの身なので、上記SQL文がそもそも間違っている、とか よりよいSQLはこうだ、みたいなご意見あればコメントいただけますと幸いです。 また、結果としてこうなる経験をしたが、なぜこのような動きとなるのかはわからない。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MySQLのdumpファイルをインポートすると文字化けする

概要 商用環境(Webシステム)をローカルに構築しように発生した問題です。 解決方法をメモとして残します。 ローカル構築時に行った手順 ソースコードをローカルにコピー MySQL立ち上げ(docker) dumpファイルをMySQLにインポート DB接続先を修正 動作確認 →MySQLのデータが文字化けしてしまっている 対応 dumpファイルのこの行を消す dump_yyyymmdd.sql /*!50503 SET NAMES cp932 */; 感想 商用環境がWindowsサーバーだったり、MySQLのversionがどうこうとか、ローカルがdockerだからとか、 色々想像で動いてしまったせいで解決に時間がかかりました。情けない!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MySQLのreplace intoはdelete insertだった件

始めに MySQLにreplace intoという構文がある。実務においてはprimary keyを確認しinsert updateする処理の代わりに使っている。最近traceテーブルを作成した際、replace intoはdelete insertする処理が行われていると気づいた。この記事ではreplace intoの内部処理を確認する。 確認 replace intoの内部処理を動的に確認するためusers・trace_usersテーブル create table users ( user_id varchar(11) default null, pw varchar(255) default null, primary key(user_id) ) engine=InnoDB default charset=utf8; create table trace_users ( dt datetime not null, dml varchar(31) not null, user_id_old varchar(11) default null, user_id_new varchar(11) default null, pw_old varchar(255) default null, pw_new varchar(255) default null ) engine=InnoDB default charset=utf8; insert・update・deleteトリガーを作成する。 create trigger trigger_before_insert_users before insert on users for each row replace into trace_users set dt = now(), dml = "before insert", user_id_new = new.user_id, pw_new = new.pw; create trigger trigger_after_insert_users after insert on users for each row replace into trace_users set dt = now(), dml = "after insert", user_id_new = new.user_id, pw_new = new.pw; create trigger trigger_before_update_users before update on users for each row insert into trace_users set dt = now(), dml = "before update", user_id_old = old.user_id, user_id_new = new.user_id, pw_old = old.pw, pw_new = new.pw; create trigger trigger_after_update_users after update on users for each row insert into trace_users set dt = now(), dml = "after update", user_id_old = old.user_id, user_id_new = new.user_id, pw_old = old.pw, pw_new = new.pw; create trigger trigger_before_delete_users before delete on users for each row insert into trace_users set dt = now(), dml = "before delete", user_id_old = old.user_id, pw_old = old.pw; create trigger trigger_after_delete_users after delete on users for each row insert into trace_users set dt = now(), dml = "after delete", user_id_old = old.user_id, pw_old = old.pw; usersテーブルにsato・suzuki・takahashiの登録しsuzukiのpwを変更する。 replace into users (user_id, pw) values ('sato', 'sato1234'); replace into users (user_id, pw) values ('suzuki', 'suzuki5678'); replace into users (user_id, pw) values ('takahashi', 'takahashi90'); replace into users (user_id, pw) values ('suzuki', 'h8ga06d8o7'); 確認結果 登録のパターンはinsert処理、変更のパターンはdelete insert処理することが判った。 dt dml user_id_old user_id_new pw_old pw_new 2022-02-23 00:40:25 before insert sato sato1234 2022-02-23 00:40:25 after insert sato sato1234 2022-02-23 00:40:35 before insert suzuki suzuki5678 2022-02-23 00:40:35 after insert suzuki suzuki5678 2022-02-23 00:40:45 before insert takahashi takahashi90 2022-02-23 00:40:45 after insert takahashi takahashi90 2022-02-23 00:40:53 before insert suzuki h8ga06d8o7 2022-02-23 00:40:53 before delete suzuki suzuki5678 2022-02-23 00:40:53 after delete suzuki suzuki5678 2022-02-23 00:40:53 after insert suzuki h8ga06d8o7
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む