この前MySQLの、whereとorder by使ってるところが糞遅かったから、
今後のためにもうちょい調べてみたんだが、
やっぱ、両方インデックスあっても、
whereのkey以外でソートする場合はインデックス使ったソートしてくれないぽいんだな。
そういう場合は、複合インデックスを使えと。

でも、
whblogで、SQLiteに複合インデックスなんか設定してないんだが、
現時点で記事数14万件でデータベースサイズ２４０MBのブログがあるんだが、
記事数少ないブログよりは遅いかなーとも思うけど、それほど遅いとも思わんのだよね。
余裕で1秒未満では終わってると思う。
SQL文は
select where order by limit offset
って感じで。
もちろん、whereとorderのkeyは別。
全件ソートしてたら時間かかるはずだよな。
MySQLで問題が深刻なのに気づいたのは40万件辺りからだが、
30秒とかかかってたから、14万件でも問題あったらわかるよな・・・
一応コマンドラインのツールで確認してみたが、
見てもよくわからんのだが、ソート用のインデックス開いてる感じはするし。
SQLiteは別々インデックスでも使ってくれてる感じなんだよな。
SQLiteだと、phpMyAdminみたいのないからインデックスの再作成とか厳しいよな。
インデックスに問題あったら修正に困るな。
まあ、記事数１４万件でも問題ないから、それ以上の記事数のブログってのは考えにくいか？w


サーバー分割も考えると、SQLiteよりもMySQLのがいいと思うんだが、
個別に複合インデックス作らんといけないなら条件ごとに作らなくちゃでインデックスの数が多くなっちゃう。
書き込み時の負担が増えまくりだよなあ・・・
ブログ別にDBわけた方がいいって利点もあるし、SQLiteの仕様にすっかなあ・・・
SQLiteでサーバー分割も、
HTTPかFastCGIプロトコルでできないこともないし・・・

まあ、これは現実的にできるかどうかもわからんし、
作りながらだな。