以下に移行しました。 kenzo0107.github.io
以下に移行しました。 kenzo0107.github.io
クラウド時代の新常識はこれだ!「MySQL クラウド向け InnoDB チューニング」 こんにちは。インフラエンジニアの nobuh です。 株式会社インサイトテクノロジー様主催の db tech showcase sapporo 2015 が 9月10日、11日の2日間にわたって開催されました 。 今回、弊社も発表する機会を頂きましたので、インフラエンジニアとして日々 MySQL と格闘して培ったノウハウについてお話させて頂きました。その発表で使ったスライドがこちらです。 クラウド上の仮想サーバーを使って MySQL の管理やチューニングに日々邁進されている方々にご覧いただけると幸いです。 今までにも MySQL に関していくつか記事を掲載していますので、この機会に是非ご覧ください! → OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」
実は非常に有用で、この機能が実は欲しかった!と言う方が続出する機能なのですよね〜 全然知らなかったのですが、mysqlでは複数レコードを1行にまとめる事ができます。 複数行をカンマ区切りにしたり、結構有効に使えそうです。 テーブル・データの準備 テーブル データ 実際に実行してみる 普通にselectしてみる group_concatしてみる group_concat + distinct group_concat + group by テーブル・データの準備 早速サンプルコードを。 テーブル mysql> create table gc1(id int auto_increment, uid int, name varchar(30), primary key(id))engine=innodb charset=utf8mb4; Query OK, 0 rows affected (0.
自動化。 どうせ誰も見ないって。 show create table 見たほうが早いし。 mysqldump --no-data -uroot --database employees をリポジトリに入れてバージョン管理しとけば良いと思うけど、 何らかの文書化が必要な場合は毎回差分を修正するより全部出力した方がラク。 カラム名日本語がよければ適当に as で別名つけるとよい。 mysqlの場合 #!/bin/bash MYSQL="mysql -B -uroot" DBNAME="employees" TBLSQL=`cat << EOD SELECT TABLE_NAME, TABLE_COMMENT FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = '$DBNAME' AND table_name LIKE '%s' EOD` CO
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
最後にSELECTした行数を取得するFOUND_ROWS()。 ページングする場合など、分母が欲しい場合があります。 たとえば100レコードあるけど、1ページに表示するデータは10レコードの場合。 普通に考えたら、10レコード取得するSELECTと、同じ条件でCOUNT(*)するSELECTを発行すると思います。 MySQLにはこういう場合用とも言える機能があります。 以下の実行例の通りです。 ま、SELECTを2回発行することに違いはないですが、スマートですよね。 ■SQL_CALC_FOUND_ROWS指定なし mysql> SELECT * FROM tbl_name LIMIT 10; ----------------------------- 10 rows in set (0.00 sec) mysql> SELECT FOUND_ROWS(); +--------------
ちょっとした小ネタです。RDS(MySQL)に於いて、『utf8mb4』に対応した環境が作成出来るか/対応しているかという件で確認する機会がありましたので、当エントリに備忘録的として記しておきます。 目次 『utf8mb4』とは RDS(MySQL)環境の用意 『utf8mb4』に対応したパラメータグループを作成・適用 『utf8mb4』関連パラメータグループ適用後の内容確認 『utf8mb4』とは この『utf8mb4』というもの、文字コードの一種で、UTF8で4バイト文字を扱う事が出来るものらしいです。 MySQLで4バイトのUTF-8文字を扱ってみる - HHeLiBeXの日記 正道編 また、それぞれのバージョンで扱う事が出来るCharacter Setの一覧も以下にメモしておきます。 MySQL :: MySQL 5.1 Reference Manual :: 10.1.13 Ch
MySQL で「Illegal mix of collations」というエラーが出ることがあります。テーブルの charset と接続の charset 等、すべてを utf8 などで統一してれば出ないので、あまり見ることはないかもしれません。 私はカラム毎に charset を指定することがあるので、時々このエラーにハマります。 たとえば、次のようなテーブルを作ったりします。 CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, email VARCHAR(320) CHARSET ascii UNIQUE, name VARCHAR(30) CHARSET utf8 ); メールアドレスの規約は、ローカル部が最大64バイト、ドメイン部が最大255バイト、それと @ の1バイトで合計最大320バイトなので、 VARCHAR(32
これは Postfix Advent Calendar 2014 の15日めの記事です。 ルックアップテーブル Postfix のルックアップテーブルは Linux だと通常は hash 形式のファイルですが、ファイルの代わりに MySQL, PostgreSQL, LDAP 等を参照することができます。 どの形式が使えるかは postconf -m コマンドで使用できる形式の一覧を見ることができます。Ubuntu だと次のようになってます。 % postconf -m btree cidr environ fail hash internal memcache nis proxy regexp sdbm socketmap sqlite static tcp texthash unix Ubuntu では deb で対応形式を追加できるようになっています。 % sudo apt-get
Postfix Advent Calendar 2014の 23日目の記事です。 PostfixでMySQLを利用する際に文字コードが不一致だと簡単にDOS攻撃を受けてしまうという記事を書こうと思っていたのですが、実は15日のAdvent Calendarにてとみたまさひろさんが文字コードの不一致について既に触れていたのでこちらはその補足みたいな記事になります。 何が危ないのか 文字コード設定に問題があるとMySQLでクエリを実行させるときにエラーを起こすことができます。このときのエラーが該当するメールだけに影響すればいいのですが、postfixの動作の関係上そのほかのメールも巻き込んで動作不良を起こしてしまいます。 この問題を悪用するとPostfixに対してサービス拒否(DOS)攻撃を仕掛けることができます。 実際に攻撃してみる 文字コードの設定に不備があるメールサーバ上で以下のコマンド
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
メリークリスマス!!やあ、良い子のみんな!!サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ!! というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID(Global Transaction ID)である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
あまりにも処理に時間がかかるようなSQLを実行してしまい、MySQLがうんともすんとも言わなくなってしまうような状況、よくありますよね。っていうか、まぁそんな状況あってはならないんですが、時たまあります。そんな時、問題となっているクエリの処理を止めたいわけです。 特定のクエリを止める方法 MySQLで実行中のクエリ一覧を見て、SQLを強制終了する方法 こちらを見てもらえればやり方は分かります。単純にMySQLに入って、show processlist;で問題のあるクエリを発見し、プロセスIDを kill するだけ。とても簡単。 複数のクエリを一括で止める方法 今回は問題のあるクエリが100個あったらどうする…?的なのを解決するエントリーです。まぁ、問題あるクエリ100個ある状況は、アプリ的に問題あるんじゃね?っていうレベルですが。 1個ずつプロセスIDをコピペして…なんてやってられないです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く