履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
MySQLの新認証方式について : DSAS開発者の部屋
native_password authentication_string カラムの内容は、 native_password が salt なしの純粋な SHA1(SHA1(password)) の先頭に、 MySQL 4.1 以前の形式と区別するための目印として "*" をつけたものです。 mysql> create user t3 identified with 'mysql_native_password' by 'password'; Query OK, 0 rows affected (0.20 sec) mysql> select Host,User,plugin,authentication_string from mysql.user WHERE User='t3'; +------+------+-----------------------+--------------
ユーザーの一覧や設定された権限などユーザーに関する情報を取得する
作成済みのユーザー一覧を確認する MySQL ではユーザーを作成すると mysql データベースの中の user テーブルに格納されます。作成済みのユーザーの一覧を取得するには mysql.user テーブルからデータを取得します。次のように実行してください。 それでは mysql.user テーブルからすべてのデータを取得して作成済みのユーザー一覧を確認してみます。 ※ すべてのカラムの値を取得すると見にくくなるので user カラムと host カラムの値だけを取得しています。1 作成済みのユーザー一覧を取得することができました。現在 6 つのユーザーが作成されています。 mysql. で始まるユーザーは自動で作成されているユーザーです。 特定のユーザーに関する情報を取得するには mysql データベースの user テーブルから情報を取得します。例えば suzuki で始まるユーザー
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
第163回 sysbench 1.0を使ってMySQLの負荷テストをする | gihyo.jp
今回はsysbench 1.0を使ってMySQLの負荷テストする方法を紹介したいと思います。 第26回 SysBenchを使ってMySQLの負荷テストをする でsysbenchについてはすでに紹介していますので、sysbenchの概要などはこちらの記事をご参照ください。以前の記事ではsysbenchのバージョンは0.4.12であり、最新のsysbenchはオプションやコマンドなどが若干異なっています。そのため、以前の記事のアップデート版として最新のsysbenchで負荷テストする方法を紹介します。 インストール方法 各OSごとのインストール方法はInstalling from Binary Packagesをご参照ください。今回はCentOS7にsysbenchをインストールしてみます。 # curl -s https://packagecloud.io/install/repositor
SQLフォーマッターFor WEB
今まで通りSQLの整形にお役立てください。 バージョンアップした際は本ページでお知らせしたいと思います。 2021/3/21追記 ・==が1トークンになるよう修正 ・[table]![column]が崩れないよう修正 ・cross join が崩れないよう修正 2019/7/1追記 ・カンマ整形前の場合にorder byはgroup byで桁ぞろえが有効にならないバグを修正 ・カンマ整形前の場合に、limit 1, 10が limit 1 , 10となるバグを修正 2018/8/28追記 ・ie11でlocalStorageが動作しなかったバグを修正 2018/8/27追記 ・localStorageに整形書式を保存するよう対応 2018/8/4追記 ・カンマ整形が前の場合、「桁ぞろえ」オプションを追加 コア部分に手を入れたため、おかしな動作をした場合はお知らせください。 2018/5/1
mysqldumpコマンドで "Unknown table 'COLUMN_STATISTICS' in information_schema (1109)" と怒られる原因と対策 - モヒカンメモ
エラーメッセージ mysqldump コマンドでMySQL上のデータのバックアップを取ろうとしたとき、下記のようなエラーが出た。 mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = '$db_name' AND TABLE_NAME = '$table_name';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109) 原因 MySQL 8以降に付属するmysqldumpでそれ以前のMySQL 5.7とかのサーバに対してダンプを実行
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9
スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー（MySQL）を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。
MySQL 5.7 クライアントの新機能（？）
ちょっと感動したMySQL 5.7.1 クライアント(mysqldではない)の新機能。 まずは取り敢えずこのBugs。 MySQL Bugs: #66583: Ctrl-C behavior violates principle of least astonishment http://bugs.mysql.com/bug.php?id=66583 mysqlコマンドラインクライアントに向かってCtrl+Cを叩くとmysqlコマンドラインクライアントが落ちるという、 ごくごく馴染みの動作に対するFeature Request。 MySQL 4.1.6からは--sigint-ignoreというオプションで(そんな昔からあったのか) SIGINTそのものを無効化してmysqlコマンドラインクライアントが終了しないようにできるものの、 これだとクエリを止めようと思ってもCtrl+Cで止まらなくな
DockerでサクッとDBからER図を作成する - Qiita
このコマンドを実行するとカレントディレクトリのschemaディレクトリに解析結果のHTMLが出力されます。 （コンテナは自動的に終了します） docker run のオプション -vオプションで指定したoutputのマウント先が出力先になります。 複数ファイル出力されるので、既存フォルダに出力しないことをオススメします。 また、--net="host"オプションを指定することで、ホストマシンと同じようにDBに接続できるようになります。 注意点 2017/07/28現在、DockerHubにsnapshotタグのイメージしか上がっていないため、 イメージ名は明示的にschemaspy/schemaspy:snapshotと指定しましょう。 （省略すると自動でlatestになる） SchemaSpyのオプション -tで指定できるDBの種類は、デフォルトだと以下の4つになります。 mysql m
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳
岡山にはオープンセミナー岡山と言う最高のイベントがあります。 okayama.open-seminar.org 昨日は id:t-wada さんや id:naoya さんの資料がホットエントリー入りしてました。 この登壇はそれと同じイベントになります。 その他の方も超豪華講師陣の中で、私が出来る精一杯の経験も踏まえたお話をさせていただきました。 speakerdeck.com この中で出て来る、データベースリファクタリングは本当に素晴らしい本です。 OracleベースなのですがMySQLだろうがPostgreSQLだろうが必ずためになる本です。 ですが、この本は既に廃刊になっており再販の予定もありません… 僕は後世に絶対必要な本の一つだと思っているので再販のためにも皆さんの要望の声を上げていただけるとうれしいです。 そしたらもしかしたら本が世に復活するかもしれません。 またSQLアンチパタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://tiny-garage.net/disable-binary-log-in-mysql8/
Mysql 5.7* パスワードをPolicyに合わせるとめんどくさい件について - Qiita
MySQLが得意なこと、不得意なこと(仮)
https://engineering.mercari.com/entry/2017/12/18/deadlock
LINEのMySQL運用について 修正版
質の高いAPIを作るための7つの習慣
