Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
TL;DR MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。 ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は mysql40dump のようなラッパーを何かしら作る必要があります(レプリケーションの情報はテーブルに保存されていてそれはダンプに含まれるから
mysqlの可変長文字列を扱う、varchar型とtext型の違いの話。 古い情報が混在していたので、ちょっと整理してメモ。 myisamの頃の話 sizeが違う 行の中身がdataか(varchar)、dataへのポインタか(text) 参照挟むので、performanceの違いがあった(varcharが早い) 今 net でぐぐって、ひっかかる情報の大半がこの話。 最近のinnodbの話 最大sizeは一緒。64kb(但し、TINYTEXT型、MEDIUMTEXT型、LONGTEXT型は名前の通り違う) varcharもtextも、中身は同じ仕組み(BLOB field / off page column) 行にdata入れるのも、外部(overflow page)への参照にするのも、行フォーマット次第(row format) 5.6で行formatのdefault は COMPACT
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
MySQL 5.7.11で導入、5.7.12で一部改良された、透過的データ暗号化をテストしたときのメモです。 とある勉強会のLTでグダグダになったので、あらためて書き直して投稿しておきます。 ※内容は無保証です。 2019/04/30 追記: MySQL 8.0 については以下の記事をご覧ください。 MySQL 8.0.16 でテーブルスペース・REDO ログ/UNDO ログ・システムテーブル暗号化 透過的データ暗号化(TDE)とは アプリケーション(SQL)側で暗号化/復号処理をしなくても、DBのデータファイルが暗号化される機能です。 データファイルや物理メディア(HDDなど)の窃取・盗難対策に有効です。 一方で、アプリケーション側にSQLインジェクションなどの脆弱性がある場合には、何の保護にもなりません。 MySQL以外のRDBMSでは 商用のOracleなどでは、かなり前から使えるよ
それは突然やってきた MySQL 8.0.14がGAされました。 dev.mysql.com まあ、MySQLは結構な頻度でリリースがありますし、「GAとはなんぞや」との名言が生まれる程度に、マイナーリリースでも機能が増える、パラメータが増える、既存パラメータのデフォルト値が変わる、といったことが発生するかわいいヤツです。 まあ、あとでリリースノート読んでみるか、と思いつつ、ビールを飲みながらYoutube垂れ流してボケーっとしているところに、新しいものが出てくるとリリースノートとソースコードを読み漁る某APIの人のツイートが深夜に流れてきて、ふと気になったのが、今回のテーマである「innodb_parallel_read_threads」です。 InnoDB: InnoDB now supports parallel clustered index reads, which can im
selectboxとかで西暦月等の選択用に、キーと値が同じ配列を範囲を指定して作りたい時。PHPで言うrange関数と同じ動きの関数を作るconst range = (start, end) => { let a= {}; for (let...
INSERTを使って新しいレコードを挿入してみましょう。SELECTと同じく使用頻度が高く、しかもその構文はとてもシンプルです。初めてデータを操作するときは緊張するものですが、とても簡単ですからまずはやってみましょう。 INSERTは、テーブルに新しいレコードを挿入します。INSERTには、新しいレコードを挿入するために、VALUESとSETの2種類の構文が用意されています。VALUESの場合は値をテーブルを構成する全フィールドに対応するように順番に指定し、SETはフィールド名と値のペアで必要な分だけ指定していきます。 INSERT ... VALUES構文 INSERT ... VALUES構文でレコードを挿入するための基本的な構文は次の通りです。 INSERT INTO テーブル名 (フィールド名 , フィールド名 ,...) VALUES(値 , 値 ,...); テーブル名の後に、
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。(もちろん、きっかは自分がドツボにはまったから) ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 (というか、これが問題なく読めて理解できる人はこの記事読む必要ない….) 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
スロークエリーログは、実行に long_query_time 秒を超える時間がかかり、少なくとも min_examined_row_limit 行を検査する必要がある SQL ステートメントで構成されます。 スロークエリーログは、実行に長い時間がかかっているため最適化の候補となるクエリーを見つけるために使用できます。 ただし、長いスロークエリーログの調査には時間がかかる場合があります。 これを簡単にするために、mysqldumpslow コマンドを使用してスロークエリーログファイルを処理し、その内容を要約できます。 セクション4.6.9「mysqldumpslow — スロークエリーログファイルの要約」を参照してください。 初期ロックを取得する時間は実行時間として計算されません。mysqld がスロークエリーログにステートメントを書き込むのは、ステートメントが実行されて、すべてのロックが解
最近mysqlなDBのクエリーの見直しとかindexの見直しにひーひー言ってるポリドッグです。 上長にはindexの使われ方を想像しながら、indexを貼っていくんだ的な事をいわれて「(゚Д゚)ハァ」みたいに思ったわけです。 僕みたいなSQL嫌いなエンジニアからしたらイミフみたいな感じだったわけです。 そんなときに弊社CTOが教えてくれた 「indexの使われ方がわからないなら、すべてのカラムにindexを貼って、EXPLAINするといいよ」 これは今まで気づかなかったし、すごく良いアプローチだと思いました。 この事をもっと早く気づけていれば人生だいぶ違ったなぁーと。 たとえばこんなテーブルがあったとします。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `
漢(オトコ)のコンピュータ道: なぜMySQLのサブクエリは遅いのか。 この記事は 2009/3/25 に書かれたもののようである。 2009年3月といえばMySQL 5.1がGAになってわずか半年、MySQL 6.0.10-alphaがリリースされた頃で、MariaDBもまだ姿を見せていない頃だ。 時は流れて2015年、MySQL 5.6がGAになって早2年半、5.7のGAマダァ-? (・∀・ )っ/凵⌒☆チンチン な頃なので、もういい加減誰か言ってくれてもいいんじゃないかと思う。 もうMySQL(5.6)は不要にINをEXISTSに書き換えたりしないんだよって mysql51> EXPLAIN SELECT * FROM Country WHERE Continent = 'Asia' AND Code IN -> (SELECT CountryCode FROM City WHER
こんにちは @kako_351です。 テスト用のテーブルを用意したいときなど、テーブル構造も中のデータもそのままで名前だけ_testとかつけてまるっとコピーする方法。 検索すればすぐ出てきますが、毎回忘れがちなので備忘録です。 また、こういう風に書けば記憶にも残るかなと思って。 2つのSQLを実行するだけ ①構造が同じテーブルを作成 LIKE演算子を使えば簡単にできます。
MySQL には管理者だけでなく色々な権限を設定したユーザーを作成することができます。ここでは phpMyAdmin を使って MySQL に新しいユーザーを作成する方法について解説します。 新しいユーザーを作成する 新しいユーザーを作成します。 phpMyAdmin に管理者ユーザーでログインして下さい。 画面上部に表示されている「ユーザーアカウント」をクリックして下さい。 ユーザーの管理画面が表示されます。作成済みのユーザーの一覧が表示されます。 MySQL のユーザーはユーザー名とホスト名の組み合わせで作成します。ユーザー名が登録されたものであっても接続元のホスト名が登録されているホストと異なっていたら MySQL へ接続することはできません。 では新規にユーザーを作成します。画面中央にある「ユーザーアカウントを追加する」と書かれたリンクをクリックして下さい。 ユーザーの新規作画面が
おすぎやんです。 XAMPP を Windows Server 2016 にインストールします。 XAMPP(ザンプ)とは、ウェブアプリケーションの実行に必要なフリーソフトウェアをパッケージとしてまとめたものです。 Apache、MySQL、PHP、Perlの4つの主要ソフトウェアとがパッケージとして含まれています。 XAMPPの名前の由来は、各アプリケーションの名前の頭文字をとっています。 X - Windows、Linux、macOS、Solarisのクロスプラットフォーム A - ApacheのA M - MySQLのM P - PHPのP P - PerlのP 本来であれば、複数のソフトウェアは個別にインストールする必要があり非常に手間がかかりますが、XAMPPは一括してインストールすることが可能で、すぐに開発や運用が開始できます。 Windows Server 2016 のインス
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか?と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型(32bit)で実現されます*1。
すんごい地味な技。 Mysqlで枠を表示させない方法。 意味わからんと思うのでこういうこと↓ mysql> select Host from user; +----------------+ | Host | +----------------+ | 127.0.0.1 | | localhost | +----------------+ 2 rows in set (0.00 sec)これを mysql> select Host from user; Host 127.0.0.1 localhostこんな感じにすることが可能。 やり方は簡単「-s」を付けるだけ # mysql -s -umysql mysql最近知ったww ていうか、これって使いどころがすごい限定される 複数列になるとこんな風になるので、逆にわかりにくかったりする。 mysql> select Host,User fro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く