>>195
それってZEROFILL属性つけた時に何桁で揃えるかで、実際何桁格納できるかには関係なかったかと。

http://dev.mysql.com/doc/refman/5.6/en/numeric-type-attributes.html

最近DBを学び始めた者ですが、複数テーブルをLEFT JOINして条件を付けた際の順序はどうなるのでしょうか？

例えば
SELECT ＊ FROM a LEFT JOIN b USING (id) LEFT JOIN c on b.no = c.no WHERE c.no IN ( 1,2,3);

の場合、aにb→cの順でjoinし、最後にwhereの条件で絞るのでしょうか？
それとも、a→b joinの後に、where → c joinとなるのでしょうか？

どなたか教えて下さい。

>>202
http://toro.2ch.net/test/read.cgi/db/1371476534/

>>202
他のRDBMSは知らないが、都度オプティマイザーがどっちが効率的かを判定して決める。

>>202
他のRDBMSは知らないが、都度オプティマイザーがどっちが効率的かを判定して決める。

インデックスについての質問です。マルチカラムインデックス作成するのってクエリ早くする上での対策として定石なんですか？

select * from hogehoge where a = 1 order by b limit 10;

とかのクエリはaとbのマルチカラムインデックス張らないとaのインデックスしか有効にならないって認識なんですが合ってますかね？

PostgreSQL普段使っててちと勉強中です。

>>206
explain して比較してみればいいんじゃないの。

>>207
explainしてインデックスの利用状況確認してるんですが、一回のソートで一つのインデックスしか使われないんですね・・・。
実際にはjoinしてwhere かけているsql文なのですが、マルチカラムインデックスを作成してもuse index句を入れないとマルチカラムインデックスが使われませんでした。

設定とかでマルチカラムインデックスを優先して使ってもらう方法ってありますか？　特定のORM使ってるので、use index入れるのが辛いので・・・。

>>208
それはデータの中身や量の問題だよ

プランナがインデックスよりスキャンのほうが好ましいと思えばそうなる

設定だとrandam_costいじれば良いが、ここMySQL板だぞ

.>>209
すいません、言葉足らずでした。PostgreSQLを普段使っててMySQLを勉強中という意味です。
案件でMySQLが多いので運用のノウハウとか知りたくて色々弄ってる最中です。

MySQLって結構クセがあるんですね。↓のようなクエリはインデックス使われないから別の方法考えた方がいいですよね？

select * from A inner join B on A.b_id = B.id where B.colum1 order by A.create_date;

間違えた・・こっちでした。

select * from A inner join B on A.b_id = B.id where B.colum1 = 'hogehoge' order by A.create_date;

>>212
DDLも書かずにそう言われても答えようがない

>>212
use indexはどうなった？利用したらどうなんだ？

Oracle、PostgreSQLなど他のRDMSからMySQLに移動してきて
移行が成功したって思った後に最初につまづくのが大体
order by、group byや複合カラム等へのインデックスの適用がされていなくて
パフォーマンスがた落ちってとこだからな。要注意

>>213
すいません、DDLはこんな感じです。

create table A (
id integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
create_date datetime
);

create table B (
id integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
column1 varchar(64)
);

>>214
ORM使ってる都合上、あんまりやりたくなかったです。でも使うのが定石なら仕方ないですね。

>>215
まじでそうですね・・・。ノウハウ積めればいいので良い経験にはなりますが、業務でこれはやりたくない・・。


ちなみにPostgreSQLに対してMySQLが優位なのって下記の点だと思ってるのですが他にありますか？
・同時接続数が増えてもパフォーマンスの劣化が起こりにくい
・レプリケーション機能が枯れているので安定性があり、情報がそこらじゅうに転がっている
・パーテショニングが比較的使いやすい
・設定が楽

オプティマイザが改良されてるMariaDBで試してみます。

>>216
a.create_dateにインデックス作れ。
オプティマイザーの問題以前に、存在しないインデックスは選びようがない。

>>217
すいません、インデックスのDDL書くの忘れていました。
a.create_dateとb.column1にはインデックス張ってます。
マルチカラムインデックスも作成したのですが、joinとorder byを組み合わせるとuse indexを指定しないとインデックスを使ってくれませんでした。

>>218
データの問題で使ってくれないだけじゃないかな？
うちではこういう結果になる (A.create_dateとB.column1はランダムで生成)

mysql> SHOW CREATE TABLE A \G SHOW CREATE TABLE B \G
*************************** 1. row ***************************
Table: A
Create Table: CREATE TABLE `A` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `A_create_date_idx` (`create_date`)
) ENGINE=InnoDB AUTO_INCREMENT=65521 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

*************************** 1. row ***************************
Table: B
Create Table: CREATE TABLE `B` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`column1` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=262135 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> EXPLAIN SELECT * FROM A JOIN B ON B.id = A.id WHERE B.column1 = CAST(RAND() AS CHAR) ORDER BY A.create_date \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: A
type: index
possible_keys: PRIMARY
key: A_create_date_idx
key_len: 6
ref: NULL
rows: 33157
Extra: Using index
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: B
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: test.A.id
rows: 1
Extra: Using where
2 rows in set (0.00 sec)

>>218
MySQLのオプティマイザはアホの子なので、ある程度データが入ったテーブルでJOINするとかなり見誤る。

USE INDEXでしのげるなら付けてあげて。。

>>219
有難うございます、そこまでやって頂いて感謝です。
おっしゃる通り、どうやらデータ量(100万件ぐらい)が若干多いせいみたいでオプティマイザがインデックス使ってくれないみたいです。

色々試してみたのですが、下記の方法でインデックスを使ってくれるようになりました。

改善前　SELECT * FROM A JOIN B ON B.id = A.id WHERE B.column1 = CAST(RAND() AS CHAR) ORDER BY A.create_date;

改善後　SELECT * FROM A JOIN B ON B.id = A.id WHERE A.create_date < now() and B.column1 = CAST(RAND() AS CHAR) ORDER BY A.create_date;

思ったより面倒な対処しなくて済みそうで良かったです、有難うございます！

>>220
そうですね・・・ちとアホの子ですね・・・。小さい規模はPostgreSQLで、大規模はMySQLでってのが少しわかりました。
小さい規模はORMでSQL文気にしないでプログラムしても大抵インデックス使われるけど、MySQLはオプティマイザを考慮したSQL文書かないとダメだからちょっと工数かかる、その代りスケールしやすいって感じなんですかね。

>>221
まず基本として
USE INDEXをつけてインデックスを使うものは
データやプランナの問題か、根本的に必要がない。
USE INDEXをつけてインデックスを使わないものは
DBの仕様の問題か、インデックスの貼りかたの問題

これPostgreSQLでも常識だろうが

で、USE INDEXをつけたときとつけないときの、応答速度はどうなんだい？

>>221
>小さい規模はPostgreSQLで、大規模はMySQL
それは気のせいだ

>>222
USE INDEXをつけてインデックスが使われた場合は0.03秒、使われなかった場合は1.2秒といった結果でした。
PostgreSQLは適当にSQL文書いても、割とインデックス使ってくれます・・・。

>>223
インデックスを使わないシークの数の上限設定ができたはず。

>>224
有難うございます、調べてみます。

PostgreSQLを触っててMySQL触りだすと
昔と違って今だと、シビアにチューニングできなければつらいだけ

ポテンシャルはMySQLのがまだ高いけど、大体はPostgreSQLに負ける

でもなんとなくgoogleとかfacebookが使ってるMySQLを使ってしまう。

そりゃシビアにチューニングできる会社だからな

同じく出来るなら使えばいいんじゃね

ホスティングとか自社サービスじゃない系はPostgreSQLかそれベースのものが増えてるからな

大規模はMySQLて何を根拠にしてんだろ？

google mysql やめるって

MariaDBにするってだけでしょ？

自力で実装しなきゃなんないシャーディンクを
標準機能とでも思ってるのでは

というか、オラクルがスキあらば金取ろうとして超うざい。
わざわざ会社にまで電話かけてくんなマンカス＞日本オラクルの馬鹿女

>>222
> >>221
> >小さい規模はPostgreSQLで、大規模はMySQL
> それは気のせいだ
元ネタはこれだな。
http://www.slideshare.net/matsunobu/ss-28303485

今となっての大きな違いはマルチスレッドかマルチコアかぐらいの違いぐらいか。

クラスタリングに関してはMySQLだろう
大規模ってそういう事じゃないの？

>>236
枯れきってるって意味ではな

サポート頼るならpostgresのがいい

>>234
読んできた。結構知識が偏ってるようで

2004年で日本は既にMySQL > PostgreSQLだったような
今は逆に、世界の方がPostgreSQLの比率が多い

postgresもamazon rdsでもサポート始まったしな
MySQLはオワコン
かといって素直にみんなMariaいくかと言えば
「まてよ」と一度考察が入るのでそうでもない。
オラクルのMySQLつぶしはほとんど成功だな

>>239
FaceBookが利用してるやり方やDeNAがやってることとか考えると
MySQLじゃないとだめな用途はちゃんとある

PostgreSQLもビッグデータ系で多々使われるようになってるし
クラウドと実は相性が良いということもあるし

どっちもこれからまだまだいける

>>240
>FaceBookが利用してるやり方やDeNAがやってることとか考えると
>MySQLじゃないとだめな用途はちゃんとある

例えばどんな？　否定でなく、単純に知りたい。

>>238
> 読んできた。結構知識が偏ってるようで


俺もそう思う。大規模の定義がFBとGoogle。この２社以外はコスト的にAWSに敵わないみたいに読める。
実際はそんな簡単じゃないんだけども。

データを自社に置くか置かないをコストだけで判断しない業種がたくさんあるわけだが、
そういう視点がすっぽり抜けてる。

>>241
FaceBookの利用は、そのURLに書いてあった内容だよ。
DeNAは
http://www.publickey1.jp/blog/10/nosqlmysqldenamemcached75.html
http://itpro.nikkeibp.co.jp/article/Interview/20110801/363141/

>>242

いや、２０１０年ころの話をされても。。。。って思った訳っす。

上のスライドの趣旨としては、２０００年－２００５年くらいの状況として
大規模はMySQLを選んだみたいに言ってるようにみえるから。

>>242

ついでにいうとFBやGoogleみたいに中身をぐちゃぐちゃに改造して
大規模対応って言われてもなぁみたいな。

中を改変しちまえば、そりゃなんでもできるじゃないという。


MySQLは大規模に向いているという理由が理解できない。

スレッドベースだとなんでLLと相性いいの？

>>243
どこにもそんな古い話ではかかれてないよ
今の話だよ

>>244
それは作者に聞いてください

MySQLがPostgreSQLより大規模に向いてるとは僕は思ってない

>>245

RDBMSのコネクションプーリングとかその辺の話 - wyukawa’s blog
http://d.hatena.ne.jp/wyukawa/20131116/1384621867

>>241

知識は偏ってるね。
まぁ、元 MySQL のサポートエンジニアでその後は WEB系でしか働いてない人だししゃーないかな。

>> 俺もそう思う。大規模の定義がFBとGoogle。この２社以外はコスト的にAWSに敵わないみたいに読める。
>> 実際はそんな簡単じゃないんだけども。
>> データを自社に置くか置かないをコストだけで判断しない業種がたくさんあるわけだが、
>> そういう視点がすっぽり抜けてる。

俺もそう思うが、そういう人は相手にしてない資料なんじゃないかな。
正直、人事系とか外に出すなんてって思っちゃうけど、
今後 AWS 使うのは普通になる世の中が来るのかね。

昔は業務系、今は WEB系で働いてるが、WEB系に関しては、
よっぽどのことがない限りコストでは AWS の RDS のほうが有利だね。
細かなチューニングとか、トラブル時の調査とかしにくいけど、
チューニング出来る人雇うぐらいならスケールアップしたほうが安いっていう。

>>248
一通り見た。
コネクションプールを使わない場合は
MySQLのがコネクションを貼るコストがスレッドだから安いから速いってことか

複数台構成の場合コネクションプール使うし
1台の場合貼りっぱなしで問題ないから理解が出来なかった