SlideShare a Scribd company logo
1 of 60
Download to read offline
とあるイルカの
バーボンハウス
2013/10/25
yoku0825
MySQL Casual Talks #5
やあ (´ ・ ω ・ `)
ようこそ、バーボンハウスへ。
このDDLはサービスだから、
まず読んで落ち着いて欲しい。
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
うん、「また」なんだ。済まない。
仏の顔もって言うしね、
謝って許してもらおうとも思っていない。
でも、このDDLを見たとき、
君は、きっと言葉では言い表せない
「ヒャッハー」みたいなものを
感じてくれたと思う。
世紀末の過ぎ去った世の中で、
そういう気持ちを忘れないで欲しい
そう思って、このDDLを書いたんだ。
じゃあ、注文を聞こうか。
( ゚ д ゚ ) ヒャッハー
跪け!
命乞いをしろ!
というわけで
●
●

yoku0825
とある企業のDBA
●
●
●

●

オラクれない
ポスグれない
マイエスキューエる

その正体は
●
●
●

嫁の夫
せがれの父
ぬいぐるみスキー
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
` オンラインでは INSERT が主で、
バッチで SELECT することがあります!
UPDATE と DELETE は基本的に
走りません! '
orz
ログテーブル。。
イイケドサ
` 保存件数は毎月 1000 万行で、
保存期間は最低 1 年です! '
orz
だったら型もうちょっと考えて。。
` パージは月ごとのテーブルに分けて
TRUNCATE しようと思うんです! '
Σ( ゚ д ゚ lll)
節子、それ 1 年保存やない、
11 か月保存や!
テーブル定義もツッコミどころ満載
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
なぜサロゲートキーを
SIGNED BIGINT にした
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
なぜ敢えて予約語を選んだ
KEY (`key`) とかギャグか
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
容量がタイトなのに
何故バイナリー文字列を CHAR 型にする
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
int(1) は 1 バイト INT じゃない
1 バイト INT は TINYINT だ
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
5.5 なら DATETIME は 8 バイトだが
TIMESTAMP は 4 バイトだ
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
何故その名前にしたのか
俺の目を見て言ってみろ
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
情報量が全くない名前をつけるな
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
aa_id はクラスタードインデックスだから
末尾につける必要はない
`3` と重複してる
CREATE TABLE `hogehoge`(
`aa_id`
bigint NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`key`
varchar(64) NOT NULL,
`cc_url`
varchar(255) NOT NULL,
`dd_json`
text,
`ee_flag`
int(1) NOT NULL,
`pp_date`
datetime NOT NULL,
`qq_date`
datetime NOT NULL,
PRIMARY KEY(`aa_id`),
UNIQUE KEY `uidx_hogehoge_01`(`cc_url`),
KEY `1`(`ee_flag`, `cc_url`, `aa_id`),
KEY `2`(`cc_url', `ee_flag'),
KEY `3`(`ee_flag`, `cc_url`),
KEY `idx_hogehoge_01`(`key`),
KEY `idx_hogehoge_02`(`pp_date`)
) ENGINE= InnoDB DEFAULT CHARSET= utf8mb4;
`2` と `3` も微妙だ
ORDER BY 狙いだから
重複じゃないっていうにしては
cc_url はユニークキーだ
orz
怖ろしいDDLしてるだろ。
ウソみたいだろ。
SQLレビュー通ってるんだぜ、
それで。
orz
` じゃあどうしろと? '
CREATE TABLE `hogehoge`(
`aa_id`
int unsigned NOT NULL AUTO_INCREMENT,
`bb_id`
int unsigned NOT NULL,
`ff_key`
varbinary(64) NOT NULL,
`cc_url`
varbinary(255) NOT NULL,
`dd_json`
blob,
`ee_flag`
tinyint NOT NULL,
`pp_date`
timestamp NOT NULL,
`qq_date`
timestamp NOT NULL,
PRIMARY KEY(`aa_id`, pp_date),
UNIQUE KEY `idx_ccurl`(`cc_url`),
KEY `idx_eeflag_ccurl_aaid`
(`ee_flag`, `cc_url`, `aa_id`),
KEY `idx_ccurl_eeflag`(`cc_url', `ee_flag'),
KEY `idx_eeflag_ccurl`(`ee_flag`, `cc_url`),
KEY `idx_ffkey`(`ff_key`),
KEY `idx_ppdate`(`pp_date`)
) ENGINE= InnoDB ROW_FORMAT= COMPRESSED
DEFAULT CHARSET= utf8mb4
PARTITION BY LIST(..) ..;
容量節約第一
ただし binary 型は Java でフェッチすると
java.lang.String じゃなくて
byte[] で戻るらしい
ガッツで何とかしてもらった
LIST パーティショニングで 24 分割
{ 偶数年 | 奇数年 } * 12 ヶ月
パーティショニング定義が超きたない
そんなにオーバーヘッドなかったから
いいことにする
と、自分に言い聞かせている
インデックスの名前は基本、カラム名
ALTER TABLE .. DROP KEY の
KEY キーワードをつけ忘れると悲惨なので
接頭辞 idx はつけることにした最近
mysql> explain
-> SELECT *
-> FROM fugafuga
-> WHERE aa_id = xx
-> AND bb_status = xx
-> AND cc_id > xx
-> AND dd_date >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
-> ORDER BY aa_id descG
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: fugafuga
type: range
possible_keys: uidx_fugafuga,
idx_fugafuga_01,
idx_fugafuga_02,
idx_fugafuga_03
key: idx_fugafuga_01
key_len: 4
ref: NULL
rows: 2
Extra: Using where; Using filesort
1 row in set (0.00 sec)
EXPLAIN 取った時に見にくい
SHOW CREATE TABLE とセットで見るけど、
10 個以上キーがあるとめげる
USE INDEX 書く時も、
WHERE を狙ってるのか
ORDER BY を狙ってるのかよく判らない
mysql> explain
-> SELECT *
-> FROM fugafuga
-> WHERE aa_id = xx
->
AND bb_status = xx
->
AND cc_id > xx
->
AND dd_date >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
-> ORDER BY aa_id descG
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: fugafuga
type: range
possible_keys: uni_aaid_eeid_dddate,
idx_dddate_bbstatus_ccid,
idx_aaid_bbstatus_ccid_dddate_ffid,
idx_ccid_bbstatus_dddate
key: idx_dddate_bbstatus_ccid
key_len: 4
ref: NULL
rows: 113055
Extra: Using where; Using filesort
1 row in set (0.00 sec)
名前から型が推測できると更にすてき
dd_date は
DATETIME 型か TIMESTAMP 型だろう
で、 key_len が 4 だから TIMESTAMP 型で
しかも先頭の dd_date 部分しか
効いてないね RANGE スキャンだもんね
mysql> explain
-> SELECT *
-> FROM fugafuga USE INDEX(idx_aaid_bbstatus_ccid_dddate_ffid)
-> WHERE aa_id = xx
->
AND bb_status = xx
->
AND cc_id > xx
->
AND dd_date >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
-> ORDER BY aa_id descG
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: fugafuga
type: range
possible_keys: uni_aaid_eeid_dddate,
idx_dddate_bbstatus_ccid,
idx_aaid_bbstatus_ccid_dddate_ffid,
idx_ccid_bbstatus_dddate
key: idx_aaid_bbstatus_ccid_dddate_ffid
key_len: 5
ref: NULL
rows: 509
Extra: Using where; Using filesort
1 row in set (0.00 sec)
どこ狙ったのかが SQL だけで伝わる
アプリのコードに直接触ら ( れ ) ない
わたしにとってこれ意思疎通が超捗る
コードだけで会話する必要はないけど、
コードで判りあうことも必要
とはいえ、 update_date とか
フレームワークが自動で生成してるの
知りませんでした orz
会話できるようになりたい orz
なお、このスライドは
フィクションであり、
実在するDDLとは
一切関係がありません
とかだったら、
いいんですけどね! :)
ご清聴ありがとうございました

More Related Content

What's hot

紹介 of Anemometer
紹介 of Anemometer紹介 of Anemometer
紹介 of Anemometeryoku0825
 
Rで触れる日本経済~RでVAR編~
Rで触れる日本経済~RでVAR編~Rで触れる日本経済~RでVAR編~
Rで触れる日本経済~RでVAR編~Kazuya Wada
 
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技yoku0825
 
Handlerさんコンニチワ
HandlerさんコンニチワHandlerさんコンニチワ
Handlerさんコンニチワyoku0825
 
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはMySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはyoku0825
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニングyoku0825
 
カジュアルにソースコードリーディング
カジュアルにソースコードリーディングカジュアルにソースコードリーディング
カジュアルにソースコードリーディングAkihiro Okuno
 
MySQLの全文検索に関するあれやこれや
MySQLの全文検索に関するあれやこれやMySQLの全文検索に関するあれやこれや
MySQLの全文検索に関するあれやこれやyoku0825
 
MySQL clients
MySQL clientsMySQL clients
MySQL clientsyoku0825
 
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーションイルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーションyoku0825
 
MySQLチューニング
MySQLチューニングMySQLチューニング
MySQLチューニングyoku0825
 
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術yoku0825
 
今から備えるMySQL最新バージョン5.7
今から備えるMySQL最新バージョン5.7今から備えるMySQL最新バージョン5.7
今から備えるMySQL最新バージョン5.7yoku0825
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Hiroshi Tokumaru
 
ぐだぐだInnoDB
ぐだぐだInnoDBぐだぐだInnoDB
ぐだぐだInnoDByoku0825
 
RailsエンジニアのためのSQLチューニング速習会
RailsエンジニアのためのSQLチューニング速習会RailsエンジニアのためのSQLチューニング速習会
RailsエンジニアのためのSQLチューニング速習会Nao Minami
 
わかった気になるMySQL
わかった気になるMySQLわかった気になるMySQL
わかった気になるMySQLyoku0825
 
MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形yoku0825
 
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyoyoyamasaki
 
Mroongaを使ったときの MySQLの制限との戦い
Mroongaを使ったときの MySQLの制限との戦いMroongaを使ったときの MySQLの制限との戦い
Mroongaを使ったときの MySQLの制限との戦いNaoya Murakami
 

What's hot (20)

紹介 of Anemometer
紹介 of Anemometer紹介 of Anemometer
紹介 of Anemometer
 
Rで触れる日本経済~RでVAR編~
Rで触れる日本経済~RでVAR編~Rで触れる日本経済~RでVAR編~
Rで触れる日本経済~RでVAR編~
 
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
 
Handlerさんコンニチワ
HandlerさんコンニチワHandlerさんコンニチワ
Handlerさんコンニチワ
 
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLはMySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
 
雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング雑なMySQLパフォーマンスチューニング
雑なMySQLパフォーマンスチューニング
 
カジュアルにソースコードリーディング
カジュアルにソースコードリーディングカジュアルにソースコードリーディング
カジュアルにソースコードリーディング
 
MySQLの全文検索に関するあれやこれや
MySQLの全文検索に関するあれやこれやMySQLの全文検索に関するあれやこれや
MySQLの全文検索に関するあれやこれや
 
MySQL clients
MySQL clientsMySQL clients
MySQL clients
 
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーションイルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
 
MySQLチューニング
MySQLチューニングMySQLチューニング
MySQLチューニング
 
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術
 
今から備えるMySQL最新バージョン5.7
今から備えるMySQL最新バージョン5.7今から備えるMySQL最新バージョン5.7
今から備えるMySQL最新バージョン5.7
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
 
ぐだぐだInnoDB
ぐだぐだInnoDBぐだぐだInnoDB
ぐだぐだInnoDB
 
RailsエンジニアのためのSQLチューニング速習会
RailsエンジニアのためのSQLチューニング速習会RailsエンジニアのためのSQLチューニング速習会
RailsエンジニアのためのSQLチューニング速習会
 
わかった気になるMySQL
わかった気になるMySQLわかった気になるMySQL
わかった気になるMySQL
 
MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形
 
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo
[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo
 
Mroongaを使ったときの MySQLの制限との戦い
Mroongaを使ったときの MySQLの制限との戦いMroongaを使ったときの MySQLの制限との戦い
Mroongaを使ったときの MySQLの制限との戦い
 

Viewers also liked

出会い駆動コミュニティー
出会い駆動コミュニティー出会い駆動コミュニティー
出会い駆動コミュニティーyoku0825
 
さんをつけろよデコ助野郎
さんをつけろよデコ助野郎さんをつけろよデコ助野郎
さんをつけろよデコ助野郎yoku0825
 
MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版Masahiro Tomita
 
My sqlで2億件のシリアルデータと格闘した話
My sqlで2億件のシリアルデータと格闘した話My sqlで2億件のシリアルデータと格闘した話
My sqlで2億件のシリアルデータと格闘した話saiken3110
 
MySQLテーブル設計入門
MySQLテーブル設計入門MySQLテーブル設計入門
MySQLテーブル設計入門yoku0825
 
MySQLと正規形のはなし
MySQLと正規形のはなしMySQLと正規形のはなし
MySQLと正規形のはなしyoku0825
 
Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験yoku0825
 

Viewers also liked (7)

出会い駆動コミュニティー
出会い駆動コミュニティー出会い駆動コミュニティー
出会い駆動コミュニティー
 
さんをつけろよデコ助野郎
さんをつけろよデコ助野郎さんをつけろよデコ助野郎
さんをつけろよデコ助野郎
 
MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版MySQLの文字コード事情 2017版
MySQLの文字コード事情 2017版
 
My sqlで2億件のシリアルデータと格闘した話
My sqlで2億件のシリアルデータと格闘した話My sqlで2億件のシリアルデータと格闘した話
My sqlで2億件のシリアルデータと格闘した話
 
MySQLテーブル設計入門
MySQLテーブル設計入門MySQLテーブル設計入門
MySQLテーブル設計入門
 
MySQLと正規形のはなし
MySQLと正規形のはなしMySQLと正規形のはなし
MySQLと正規形のはなし
 
Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験
 

Similar to とあるイルカのバーボンハウス

Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Makoto Haruyama
 
高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方GMO-Z.com Vietnam Lab Center
 
高負荷に耐えうるWeb application serverの作り方
高負荷に耐えうるWeb application serverの作り方高負荷に耐えうるWeb application serverの作り方
高負荷に耐えうるWeb application serverの作り方yuta-ishiyama
 
[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法LINE Corporation
 
TDEで透過的暗号化
TDEで透過的暗号化TDEで透過的暗号化
TDEで透過的暗号化furandon_pig
 
コンピューティングとJava~なにわTECH道
コンピューティングとJava~なにわTECH道コンピューティングとJava~なにわTECH道
コンピューティングとJava~なにわTECH道なおき きしだ
 
GoCon 2015 Summer GoのASTをいじくって新しいツールを作る
GoCon 2015 Summer GoのASTをいじくって新しいツールを作るGoCon 2015 Summer GoのASTをいじくって新しいツールを作る
GoCon 2015 Summer GoのASTをいじくって新しいツールを作るMasahiro Wakame
 
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -Hayato Mizuno
 
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和schoowebcampus
 
『データ解析におけるプライバシー保護』勉強会 秘密計算
『データ解析におけるプライバシー保護』勉強会 秘密計算『データ解析におけるプライバシー保護』勉強会 秘密計算
『データ解析におけるプライバシー保護』勉強会 秘密計算MITSUNARI Shigeo
 
vImageのススメ(改訂版)
vImageのススメ(改訂版)vImageのススメ(改訂版)
vImageのススメ(改訂版)Shuichi Tsutsumi
 

Similar to とあるイルカのバーボンハウス (12)

Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2Mysql casual fukuoa_vlo_2
Mysql casual fukuoa_vlo_2
 
高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方高負荷に耐えうるWebApplication Serverの作り方
高負荷に耐えうるWebApplication Serverの作り方
 
高負荷に耐えうるWeb application serverの作り方
高負荷に耐えうるWeb application serverの作り方高負荷に耐えうるWeb application serverの作り方
高負荷に耐えうるWeb application serverの作り方
 
[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法
 
TDEで透過的暗号化
TDEで透過的暗号化TDEで透過的暗号化
TDEで透過的暗号化
 
コンピューティングとJava~なにわTECH道
コンピューティングとJava~なにわTECH道コンピューティングとJava~なにわTECH道
コンピューティングとJava~なにわTECH道
 
GoCon 2015 Summer GoのASTをいじくって新しいツールを作る
GoCon 2015 Summer GoのASTをいじくって新しいツールを作るGoCon 2015 Summer GoのASTをいじくって新しいツールを作る
GoCon 2015 Summer GoのASTをいじくって新しいツールを作る
 
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -
Hello jQuery - 速習jQuery +綺麗なコードを書くためのヒント -
 
Login
LoginLogin
Login
 
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和
ノンプログラマーでも明日から使えるJavaScript簡単プログラム 先生:柳井 政和
 
『データ解析におけるプライバシー保護』勉強会 秘密計算
『データ解析におけるプライバシー保護』勉強会 秘密計算『データ解析におけるプライバシー保護』勉強会 秘密計算
『データ解析におけるプライバシー保護』勉強会 秘密計算
 
vImageのススメ(改訂版)
vImageのススメ(改訂版)vImageのススメ(改訂版)
vImageのススメ(改訂版)
 

More from yoku0825

逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分かyoku0825
 
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれやMySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれやyoku0825
 
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいことMySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいことyoku0825
 
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略片手間MySQLチューニング戦略
片手間MySQLチューニング戦略yoku0825
 
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろうMySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろうyoku0825
 
MySQLアンチパターン
MySQLアンチパターンMySQLアンチパターン
MySQLアンチパターンyoku0825
 
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLMHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLyoku0825
 
5.7の次のMySQL
5.7の次のMySQL5.7の次のMySQL
5.7の次のMySQLyoku0825
 
mikasafabric for MySQL
mikasafabric for MySQLmikasafabric for MySQL
mikasafabric for MySQLyoku0825
 
とあるイルカの近況報告
とあるイルカの近況報告とあるイルカの近況報告
とあるイルカの近況報告yoku0825
 
MySQL Fabricでぼっこぼこにされたはなし
MySQL FabricでぼっこぼこにされたはなしMySQL Fabricでぼっこぼこにされたはなし
MySQL Fabricでぼっこぼこにされたはなしyoku0825
 
MySQLおじさんの逆襲
MySQLおじさんの逆襲MySQLおじさんの逆襲
MySQLおじさんの逆襲yoku0825
 
地雷職人の朝は早い
地雷職人の朝は早い地雷職人の朝は早い
地雷職人の朝は早いyoku0825
 
MySQL5.7で遊んでみよう
MySQL5.7で遊んでみようMySQL5.7で遊んでみよう
MySQL5.7で遊んでみようyoku0825
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことyoku0825
 

More from yoku0825 (15)

逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
 
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれやMySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれや
 
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいことMySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
 
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
 
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろうMySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
 
MySQLアンチパターン
MySQLアンチパターンMySQLアンチパターン
MySQLアンチパターン
 
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQLMHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQL
 
5.7の次のMySQL
5.7の次のMySQL5.7の次のMySQL
5.7の次のMySQL
 
mikasafabric for MySQL
mikasafabric for MySQLmikasafabric for MySQL
mikasafabric for MySQL
 
とあるイルカの近況報告
とあるイルカの近況報告とあるイルカの近況報告
とあるイルカの近況報告
 
MySQL Fabricでぼっこぼこにされたはなし
MySQL FabricでぼっこぼこにされたはなしMySQL Fabricでぼっこぼこにされたはなし
MySQL Fabricでぼっこぼこにされたはなし
 
MySQLおじさんの逆襲
MySQLおじさんの逆襲MySQLおじさんの逆襲
MySQLおじさんの逆襲
 
地雷職人の朝は早い
地雷職人の朝は早い地雷職人の朝は早い
地雷職人の朝は早い
 
MySQL5.7で遊んでみよう
MySQL5.7で遊んでみようMySQL5.7で遊んでみよう
MySQL5.7で遊んでみよう
 
MySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいことMySQL 5.7にやられないためにおぼえておいてほしいこと
MySQL 5.7にやられないためにおぼえておいてほしいこと
 

とあるイルカのバーボンハウス