MySQL 5.7の透過的データ暗号化 - Qiita
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をdisる会 - Qiita
はじめに やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけなので内容はありません。いいね？ mysql には罠がいっぱい そうなんですよ罠がいっぱいなんですよ奥さん。 いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの！ MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォル
mysqlで文字コードをutf8にセットする - Qiita
mysqlの文字コードはチェックする場所が多いので原因を突き止めるのに毎回苦労します。 大きく二種類に分けられて、 クライアント側、サーバー側（mysqlサーバー）、及びそれらの接続の文字コード データベース/テーブル/カラムの文字コード です。 デフォルトをきちんと設定しておく そもそも作成したDBの文字コードが意図しない設定になっていたら、デフォルトの設定が間違っている可能性が高いので、再度同じ問題を起こさないためにも、設定見直し→DBをdrop→DBをcreateという順番で直しに行きます。 1も2もデフォルトの設定は下記を実行すればok。 +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+-----------
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
貧乏だってプロファイリングは出来る！！ - poor man's profiler
従来より、プロファイリングのためのソフトウェアと言えば高価なものが中心であった。もっと安く、お金を掛けずに、簡単に、早くプログラムのボトルネックを探し出す方法はないのか？！ということで編み出されたプロファイリングテクノロジーがある。その名も、「poor man's profiler」だ。 poor man's profilerの全容は、次のページで知ることが出来る。 Poor Man's Profiler http://poormansprofiler.org/ poor man's profilerは、現Facebook（元MySQL ABのサポートエンジニア）のDomas Mituzasによって開発されたプロファイリングテクノロジーである。以下が、その全ソースコードである。 #!/bin/bash nsamples=1 sleeptime=0 pid=$(pidof mysqld) f
MySQLコミュニティ騒然！MySQL 5.5.4が与えるインパクト。
先週、MySQL Conference & Expo 2010が開催され、盛況のうちに終了した。カンファレンスに合わせる形で、MySQL 5.5.3および5.5.4がリリースされたのだが、これが目を見張るような進化を遂げている。特に性能面での進化には目を見張るものがある！Jeremy ZawodnyやMark Calleghanといったコミュニティの重鎮たちも「非常にエキサイティングなリリースだ！」などと表して歓迎の意を表している。 というわけで、本日はMySQL 5.5.3/5.5.4の新機能および変更点についてレビューしてみよう！ おさらい。 〜 MySQL 5.5の既存の機能 〜MySQL 5.5が登場したとき、その新機能については以前にもエントリで紹介したが、ここで改めておさらいしてみよう。MySQL 5.5は、正確にいうと現在最新バージョンであるMySQL 5.1の「次の次」のバ
MySQL のコネクションタイムアウトと削除されたプロセスのコネクションの残留
だいぶ前にロプローから MySQL データベースのコネクションの生存期間について聞かれてたんですが、返事するの忘れてたので今頃ブログ書いてます。どっちかって言うと忘れてたというよりは、手元の環境で問題が再現できないので放置してた感じですがw まず MySQL コネクションはデフォルト 8 時間でタイムアウトします。 関係しているシステムパラメータは wait_timeout か interactive_timeout のいずれかです。CGI の場合は通常 wait_timeout が関係します。詳細は http://dev.mysql.com/doc/refman/5.1/ja/server-system-variables.html をご覧ください。 システムパラメータの確認は SHOW VARIABLES コマンドで行えます。以下はポックン家のテスト用環境の値です。 mysql> SH
max_join_sizeパラメータに関するメッセージについて - shibainu55日記
前回(MySQL table_cacheの設定に関して)に引き続き、MySQLネタ。自宅システム内の32bit Linuxプラットフォーム上のMySQLで、mysqld_safeのログに気になるメッセージ。今回はこの件について考える。ポイントとなるパラメータはmax_join_size。これは、一回の結合クエリで保持できる最大データサイズを指定するパラメータである。 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 メッセージが出る理由の考察 プログラムを書く方ならおやっと思うかもしれないが、「4294967295」という数値は、unsigned int(32)の上限値(4G)で、「18446744073709551615」は、unsigned int(6
MyISAMでテーブルが巨大すぎるとDELETEできなくなる件（MERGEテーブル解説） - 昼メシ物語
MySQL4.1でMyISAMを使っていて、ふと気づいたら1つのテーブルに4千万件のレコードを挿入してしまいました。 MyISAMで4千万行のテーブルを作るとどうなるかというと、 INSERT -> やや重いけどいける UPDATE -> やや重いけどいける TRUNCATE/DROP -> 一瞬 DELETE -> 破滅 という感じになることが分かりました。 このテーブルには、挿入日を示すカラムがあって、挿入から時間の経った古いレコードを削除したかったんです。 DELETE FROM large_table WHERE created_at > :expire_date この large_table が4千万行あるのですが、このDELETE文を実行したら7日間くらい返ってきませんでしたし、その間ずっと disk busy になったりしてサーバの調子が悪くなりました。 created_at
MySQLでレプリケーションのメモ - 記憶Log
まずマスター側でバイナリログの出力と識別IDの設定 MySQLのmy.cnfを設定 識別ＩＤはほかとかぶらないようにする [mysqld] log-bin ←バイナリログの設定 server-id=1 ←識別ＩＤMySQLを再起動 スレイブ側の識別IDを設定 [mysqld] server-id=2 ←識別ＩＤマスター側と同じようにmy.cnfを変更したらMySQLを再起動 マスター側にレプリケーションの権限ユーザ作成 スレイブ側からマスター側に接続する時のユーザ mysql> GRANT REPLICATION SLAVE ON *.* TO repl_user@99.999.99.999 IDENTIFIED BY 'repl_passwd'; ↑スレイブ側のIPを入れる Query OK, 0 rows affected (0.01 sec) マスター側のDBのバックアップ＆スレイブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysqldump: Got error: 1: "Can't create/write to file '*.txt' (Errcode: 13 "Permission denied")" when executing 'SELECT INTO OUTFILE'
What are practical differences between `REPLACE` and `INSERT ... ON DUPLICATE KEY UPDATE` in MySQL?
よく使うmysqldumpのオプションと使用例 - Qiita
error in your SQL syntax creating MySQL trigger
http://wannabe-note.com/1078
http://www.powerdee.com/it/mysql/backupRecovery.html