こんばんは。

> 断片化が発生しても、断片の先頭はもとのレコードと同じ位置に書かれ、並び順は断片の先頭順に並びそうだから…という感じです。


なるほど。
自分も可変長カラムにUPDATEが走るケースは厳しいかと思っていましたが
断片先頭は保存されていそうですね。

詳細な情報ありがとうございました。
お手数おかけいたしました。




2015年7月10日 12:47 yoku ts. <yoku0825@xxxxxxxxxx>:
> こんにちは。

>

>> 「そのテーブルは過去にDELETE操作をされたことがない」

>> 「mysqldumpではなく、コールドバックアップでとった.MYDがある」

>> という状況であれば、同じデータが再現できる、という認識であっていますでしょうか。

>

> UPDATEだけでもvarcharのカラムがフラグメントを作っちゃうので再現できないかと思ったんですが、

> 試してみた限りではUPDATEとINSERTだけなら再現できるんじゃないかって気がしました。

>

> https://gist.github.com/yoku0825/6ae9dc58598f7084410d

>

>

> 断片化が発生しても、断片の先頭はもとのレコードと同じ位置に書かれ、並び順は断片の先頭順に並びそうだから…という感じです。

> 考慮漏れがないか自信がないんですが、俺自身が同じ難題を突きつけられたら「とりあえずこのレコードが容疑者1」って感じにすると思います。

>

> DELETEが全くない && mysqldumpでも確実にキーが使われていなかったことが保証できるなら、

> mysqldumpからのリストアでも同じ要領で再現できるかも知れません。

>

> 自信はないです。すいません(´・ω・｀)

>

>

>> > バイナリーログが残っていてbinlog_format= MIXEDかROWならそちらから追えるかも知れません。

> <snip>

>> 当時のものはないので、諦めていました。

>

> 残念です＞＜

>

>

> ( ´-｀).oO(しかし、難題ですね。。

>

>

> yoku0825,

>

> 2015年7月9日 20:49 林正紀 <hayashi.masa.norii@xxxxxxxxxx>:

>> yoku0825さん

>>

>> 丁寧なご回答ありがとうございます。

>> 諸々事情が理解出来ました。

>>

>>> バックアップが物理ファイルであれば可能性はあるかも知れませんが、「ダンプデータ」ということはmysqldumpっぽいですよね…？

>>

>> はい、ダンプデータはmysqldumpで取得したものです。

>>

>> 説明のgist拝見したのですが、MyISAMはDELETEのあとINSERTがあると

>> 開いた隙間を埋めるように動作するとのことですが

>> 「そのテーブルは過去にDELETE操作をされたことがない」

>> 「mysqldumpではなく、コールドバックアップでとった.MYDがある」

>> という状況であれば、同じデータが再現できる、という認識であっていますでしょうか。

>>

>>> バイナリーログが残っていてbinlog_format= MIXEDかROWならそちらから追えるかも知れません。

>>

>> そうですね。。。こちらはその「過去の時点」が少々古く

>> サーバのHDDの制約で定期的に消してしまっているので

>> 当時のものはないので、諦めていました。

>>

>> 林 正紀

>>

>> 2015年7月9日 20:13 yoku ts. <yoku0825@xxxxxxxxxx>:

>>> こんばんは、yoku0825といいます。

>>>

>>> わたしもマニュアルに見つけられなかったんですが、

>>> 実装上は「条件が揃えば同じレコードが返る」です。

>>>

>>> テーブルスキャンの場合、

>>> * InnoDBではクラスターインデックスの昇順に並びます

>>>   * PRIMARY KEYがあればPRIMARY KEY,

>>>     PRIMARY KEYがなくてUNIQUE KEYがあれば最初に定義されたUNIQUE KEY,

>>>     どちらもなければ6バイトの暗黙の行ID順に並べられます。

>>>

>>> https://gist.github.com/yoku0825/6d3cae7b5fb2744fe801#file-innodb_pk-md

>>> https://gist.github.com/yoku0825/6d3cae7b5fb2744fe801#file-innodb_nonpk-md

>>>

>>> MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.13.2 クラスタインデックスとセカンダリインデックス

>>> http://dev.mysql.com/doc/refman/5.6/ja/innodb-index-types.html

>>>

>>>

>>> * MyISAMの場合は物理的に.MYDファイルに入っている順番で並びます

>>>

>>> https://gist.github.com/yoku0825/6d3cae7b5fb2744fe801#file-myisam-md

>>>

>>>

>>> 何らかのキーを選んでいた場合、そのキーの並び順になります。

>>>

>>> InnoDBでPKがあれば、同じデータ同じSQLで再現可能だと思います。

>>> InnoDBでPKなし、MyISAMの場合は保証が難しいです。

>>> バックアップが物理ファイルであれば可能性はあるかも知れませんが、「ダンプデータ」ということはmysqldumpっぽいですよね…？

>>> その場合、mysqldumpがテーブルをSELECTした時に何のインデックスも使わずにデータを読んでいれば…とか微妙な気がします。

>>>

>>> https://gist.github.com/yoku0825/6d3cae7b5fb2744fe801#file-myisam_mysqldump-md

>>>

>>>

>>> 内部的な事情でいうと、

>>> * handler::ha_rnd_init が呼ばれる

>>>   * こいつが ha_innobase::rnd_init や ha_myisam::rnd_init を呼ぶ

>>> * handler::ha_rnd_next が呼ばれる

>>>   * こいつが ha_innobase::rnd_next や ha_myisam::rnd_next を呼ぶ

>>> * HA_ERR_END_OF_FILE が返るまで rnd_next を呼ぶループ

>>> です。詳しく知りたい場合はこのあたりを丁寧に追う感じになると思います。

>>>

>>>

>>> バイナリーログが残っていてbinlog_format= MIXEDかROWならそちらから追えるかも知れません。

>>> とか思いました（もう検討済みですかね。。

>>>

>>>

>>> yoku0825,

>>>

>>>

>>>

>>> 2015年7月9日 15:08 林正紀 <hayashi.masa.norii@xxxxxxxxxx>:

>>>> ORDER BY句を指定しなかった場合、SELECT文で取得するデータの並び順についての質問です。

>>>>

>>>> 一般的なSQLでは、ORDER BY句を指定しなかった場合、

>>>> その検索結果の並び順は保証されないものと認識しています。

>>>> MySQLにおいても、仕様上はそうであったと記憶しています。

>>>> （マニュアルの記述箇所がみつけられなかったのですが）

>>>>

>>>> こちらについて、「実装レベル」では実際どうなのか

>>>> （本当に仕様通り不定なのか、実際には必ずなにがしかの順序で変えるのか）を知りたいのです。

>>>>

>>>> 具体的には、過去に実行したSQLが判明しており

>>>> そのSQLで具体的にどのレコードが抽出されたかを特定したく

>>>> その過去の時点のダンプデータもあるのですが

>>>> 該当SQLがORDER BY句を含んでおらず、LIMITが指定されており

>>>> （例えば SELECT * FROM some_table LIMIT 1 のようなSQLです）

>>>> 過去流したSQLとそのダンプデータで実行した結果が

>>>> そのSQLを流した当時のものと同じレコードがセレクトされるかが保証できるかを確認したいのです。

>>>>

>>>> 調査したいSQLも、実行計画が full scanになるようなクエリです。

>>>> また、その該当テーブルにはデータはINSERT/UPDATEはされますが、DELETEはされません。

>>>> UPDATEが走るので、カラムレベルでは完全に同じレコードが再現できない可能性はありますが

>>>> 同じレコード（同じPKのレコード）が得られるかどうかが知りたいです。

>>>>

>>>> MySQLのバージョンは、5.1系

>>>> ストレージエンジンはMyISAM / InnoDB それぞれについてです。

>>>>

>>>> どなたかご存知のかたいましたら、ご教示いただけますでしょうか。

>>>> 以上、よろしくお願いいたします。