実際よりも、すべてが間違っていると想定する傾向があるようだね。
ブロックインデックスの書き込みは軽い作業だ。txインデックスの構築は1ブロックあたりのランダムアクセスがはるかに多い。すべてのprev txinの読み取りが遅い原因ではないかと疑っている。読み取りキャッシュが役立つだろう。DBがそれを行うのが最善だ。キャッシュメモリーの使用量の設定があるかもしれない。
ジェフ・ガージックの投稿（2010年11月29日19:01 UTC）
- Bitcoinはプログラム起動時にenvironmentだけでなくデータベースも開き、プログラム終了時にデータベースを閉じるべきだ。
すでにそうしている。CDBを参照してくれ。（例えば）CTxDBオブジェクトの寿命は、データベーストランザクションのサポートと、シャットダウン時にまだデータベースを使用しているものがあるかどうかを知るためだけだ。
ジェフ・ガージック加えて、Bitcoinはデータベースチェックポイントを強制し、ログから全トランザクションをメインデータベースに押し込む。
そうしていたらはるかに遅くなるだろう。1分または500ブロックに1回のみのはずだ：
if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);おそらくこれを追加すべきだ：
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);
- 初回ブロックダウンロードでは、txnコミットはレコードごとではなくNレコードごとに1回行うべきだ。N=1000を提案する。
トランザクションコミットはフラッシュを意味するのかな？ 私には意外に思える。トランザクションでラップされたデータベース操作は、他のデータベース操作と同様にログに記録されると思う。多くのデータベースアプリケーションでは、ほぼすべての操作のペアをトランザクションでラップする必要がある。例えば、あるアカウントから別のアカウントへの送金（aを借方、bを貸方）などだ。すべてを自分でバッチ処理することが求められるとは想像できない。
以下のケースで、ケース1は1回フラッシュし、ケース2は2回フラッシュするのだろうか？
ケース1：write write write write checkpoint
ケース2：begin transaction write write commit transaction begin transaction write write commit transaction checkpoint
データベースの使用方法を歪めるのは正しいアプローチではないだろう。BDBの設定とキャッシュで対応すべきだ。