実際よりも、すべてが間違っていると想定する傾向があるようだね。
ブロックインデックスの書き込みは軽い作業だ。tx インデックスの構築は 1 ブロックあたりのランダムアクセスがはるかに多い。すべての prev txin の読み取りが遅い原因ではないかと疑っている。読み取りキャッシュが役立つだろう。DB がそれを行うのが最善だ。キャッシュメモリーの使用量の設定があるかもしれない。
ジェフ・ガージックの投稿（2010年11月29日 19:01 UTC）
- bitcoinはプログラムの起動時に環境だけでなくデータベースを開き、プログラムのシャットダウン時にデータベースを閉じるべきです。
すでにそうしている。CDB を参照してくれ。（例えば）CTxDB オブジェクトの寿命は、データベーストランザクションのサポートと、シャットダウン時にまだデータベースを使用しているものがあるかどうかを知るためだけだ。
ジェフ・ガージックの投稿（2010年11月29日 19:01 UTC）加えて、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 の設定とキャッシュで対応すべきだ。