まず前提として、
1. SQLite(だけじゃないけど、auto commitがあるRDBMS)では明示的にトランザクションを開始せずに
更新系のSQLを発行すると、自動的にその文の前後でbegin、commit相当の処理が動く。
2. そしてSQLiteの場合、サーバを持たないため、トランザクションが完了していると言うことは、
HDD上のsqliteファイルに完全にデータが書き込まれていることを保証しなければいけない。
3. SQLiteがHDDへのデータの書き込みを完全に保証するためには、HDDのプラッタが2回転するのを待つ必要がある。
一般的な7200rpmのHDDは1分に7200回転＝1秒に120回転なので、1秒につき60回のトランザクションが限界(※)。
( 出典: http://www.sqlite.org/faq.html#q19 )
※実際にはデータの書き込みも行うので、それよりも少ないはず。
つまり、明示的にトランザクションを開始せずにUPDATE文を大量に発行すると、一回UPDATEするごとに
HDDへの書き込みを保証する必要が出る＝HDD速度に引っ張られる、というのが、>>176がどこかで見聞きした
「SQLiteはトランザクションで挟まないと遅い」という怪しい話の正体。
# 余談だけど、そんなわけで同じSQLiteでもインメモリDBだと、そういうことにはならない。SSDとかでも大丈夫なんじゃないかな…？
その上で。
>>174のSQL文を見ると、BEGIN文をロック種別の指定なしで発行している。
ドキュメント(>>1)を見ると、指定無しの規定値はBEGIN DEFERREDだと書いてある。
SELECT文に変えると実行される理由はDEFERREDのドキュメントを参照してもらうとして、
UPDATEした時にエラーになった理由は>>174のエラーメッセージ通りなので、
考えられる原因としては、その3行の前に手動でbegin文を打っているけど忘れているか、
そのPupSQLiteとかいうツールが変なことをしているか。後者ならツールの作者に聞かないと分からん。
