とある件で設計されたテーブルを見てたらちょっと心配になった．
MySQLのAUTO_INCREMENTを使ったシリアル値のカラムがint型になっている．

intの限界値はsignedとして2147483647．
1秒に1個消費すると仮定すると，1日で86400．1年で31536000．
これだとintのシリアル値は68年で使い切る．

システム寿命を長く見て20年としても，3倍の容量があるので十分な値と言える．
しかし，1秒に10個だと6年，1秒に100個だと248日で使い切るのでアウトだ．

twitterのidが32bit限界値を突破したのっていつでしたっけか．
まぁいずれにしろ無いことも考えられない話ではないので，データ量の見積もりを再度確認して，bigintに変更．
（実際に届くかどうかは別として「ありえる」状況を想定しているので）

で，bigintにすると最大値が9223372036854775807．
1秒に1億個消費しても使い切るのに2900年以上かかる．
これはこれでデカすぎだがｗ
まぁ安心だなぁ．

システム負荷とか，その他関数に通したときの問題がありそうなので，単純に「ユニークな値」として以外の期待を持つといろんなところでトラブルが予想される．
ということで，ちゃんと悩んで決めようなー．

#####

twitterのユーザー数を5000万人とする．
各ユーザーが1時間に10回ずつつぶやくとして，1日の総ツイート数は120億．
年間365日をかけて4兆3800億．
しかしbigintをこれで割っても210万．つまりこの想定だとtwitterが次にbigint問題(?)を迎えるのに210万年かかるということになる．
bigintすげぇなぁ．

# 計算の桁間違ってないよな…

とあるwebサーバで障害発生！応答がないから強制リセット再起動！
なんか挙動が怪しいから別サーバに引っ越そうぜ！
ということでバックアップを取ります．

# mysqldump -u hoge -p hoge > dump.sql
mysqldump: Got error: 1146: Table 'hoge.fuga' doesn't exist when using LOCK TABLES

あれ，ロック時にfugaが無いとか意味不明なことを…
とりあえずロックなしでも問題なさげなのでさらに指定．

# mysqldump -u hoge -p hoge --skip-lock-tables > dump.sql
Error: Couldn't read status information for table fuga ()
mysqldump: Couldn't execute 'show create table `fuga`': Table 'hoge.fuga' doesn't exist (1146)

あれ，やっぱりfugaが無いんじゃないの．

/var/lib/mysql/hoge/の中をを見てみると，他のテーブルはみんな *.frm, *.MYD, *.MYIの3ファイルセットなのに，fugaだけfuga.frmしかない．

phpMyAdminで見るとテーブル一覧にfugaが無い．
コマンドラインのmysqlからshow tablesするとfugaはある．

どうもリセット時に飛んじゃったっぽいですね．
幸い，頻繁に更新するテーブルじゃなかったので，1ヶ月前のバックアップから中身を取り出せます．

しかしこのエラーのおかげでmysqldumpが完走しない．
ということで，とりあえず/var/lib/mysql/hoge以下を全コピー．
別サーバに持って行きます．

別サーバのmysql上，同名でDB作成．
mysqldを止めて，旧サーバから持ってきたファイルを上書きします．
中途半端なfrmだけのテーブル用ファイルは削除．
1ヶ月前のバックアップから該当テーブルのSQLを流し込んで一応復旧．

しかしこのままだとなんか不安が残るので，あらためて全文をdumpしてから再度流し込み．
その後は特に問題なく動いているようです．

銀座に出かける用事があったので，帰りにソニーのショールームに寄ってXperiaを見てきました．
実際に触って試用できました．





以下，現在HT-03Aを持ってる自分の感想．

でかい，重い
高精細，画面広い，ヌルヌル動く
カメラ性能高い
Mediascape，Timescapeはいい感じ
動作は速いんだけど，プログラム上?メモリアクセスの都合上?たまにひっかかる.HT-03Aでもよくある．
POBox Touchも性能は良いのかな？
でもフリックのほうが楽なのでどれぐらいサクサク動くか試してみたい

まだiPhone3GSのほうがストレスは無い気がする．XperiaでやっとiPhone3Gに追いついた感じ．

買うか？と言われると
今はN-06AとHT-03Aの2台持ち状態なので，買わない．大きくて重いので．
N-06Aから乗り換え＆1本化は検討するかも．HT-03Aを持ってわかったことは，俺はiMODEコンテンツを使わないということなので．
メールに関してはiMODE.netとiMoniで代用が利くので，それならありかなー．

あとは値段次第．機種変で3万程度だったら行ってしまうかもしれない．
しかしNexusOneを見てからにしたい気持ちがまだ強いなー．

PHPで文字列変数に添字をつけると文字がとれる！
（なんかやだなーこの仕様）

ということで挙動を見てみました．PHP5.1.6上．

$a='12345';
$b=12345;
$c=array('x','y','z');

として，それぞれvar_dump．

a : string(5) "12345"
a[0] : string(1) "1"
a[1] : string(1) "2"
a[2] : string(1) "3"
a[3] : string(1) "4"
a[4] : string(1) "5"
a[5] : string(0) ""
a[6] : string(0) ""
a[7] : string(0) ""

b : int(12345)
b[0] : NULL
b[1] : NULL
b[2] : NULL

c : array(3) {
[0]=>
string(1) "x"
[1]=>
string(1) "y"
[2]=>
string(1) "z"
}
c[0] : string(1) "x"
c[1] : string(1) "y"
c[2] : string(1) "z"
c[3] : NULL
c[4] : NULL
c[5] : NULL

a[5]とか文字列の範囲外にアクセスしたときに何でNULLじゃなくて空文字列なんだろう…．

ちなみにdisplay_errorsをonにして見ると
a[5]～a[7]は「Uninitialized string offset」のnoticeが，
c[3]～c[5]は「Undefined offset」のnoticeが出ます．
なぜb[0]～b[2]には出ない…

ついでに

$a[10]='h'

とすると

a : string(11) "12345     h"

こちらは仕様通り，間にスペースが入れられます．
（「文字列への文字単位のアクセスと修正」参照）

じゃあマルチバイトだとどうなのよ！

$a="あいうeお"

として（文字コードUTF-8，mb_internal_encodingも指定）

a : string(13) "あいうeお"
a[0] : string(1) ""
a[1] : string(1) ""
a[2] : string(1) ""
a[3] : string(1) ""
a[4] : string(1) ""
a[5] : string(1) ""
a[6] : string(1) ""
a[7] : string(1) ""
a[8] : string(1) ""
a[9] : string(1) "e"
a[10] : string(1) ""
a[11] : string(1) ""
a[12] : string(1) ""
a[13] : string(0) ""
Notice: Uninitialized string offset: 13

とりあえずはこういうもんだと思っておくしかないな．
そもそもこんな形でアクセスしないで済むように書けばいいんですけどね．

「このカラム内，2～3～1の順番でソートして欲しいんですけど！」

2,3,1でそれぞれSELECTして最後にUNIONするしかないか，と思ったが，
MySQLの場合はORDER BY field({colname},{val}[,val...]) という感じで書けるらしい．

name	type
A	1
B	2
C	3
D	4

というテーブルordertestがあったとして

SELECT * FROM ordertest ORDER BY field(type,2,1,4,3);
B 2
A 1
D 4
C 3

という感じで行ける．
しかし中途半端に指定した場合はそこだけ有効になる．

SELECT * FROM ordertest ORDER BY field(type,4,2);
A 1
C 3
D 4
B 2

という感じ．
fieldに指定されなかった部分は不定のようです? アテにしないほうがよさげ．

ORDER BY filed(～),field(～) と指定することもできます．
これとCASE文の組み合わせで結構いろいろできますね．

CentOS5.4でのPHPはまだ5.1系なので，5.2系以降対応になっているjson関数（json_decode等）が使えません．
がんばってPHPを5.2に上げるという手もありますが，それは一苦労．
しかしマニュアルにある通りPECLでリリースされているので，追加してやれば使えます．
（むしろPECLであったものが5.2で標準になった）

# pecl install json
# echo 'extension=json.so' > /etc/php.d/json.ini
# service httpd restart

phpinfoでpeclを確認．問題なく動きました．