正如我在前段時間this的問題所述，我在從Python訪問sqlite數據庫時遇到性能問題。爲了再次表明這一點，使用apsw的相同代碼運行速度提高了20倍以上。我最近並行安裝了不同版本的Python，併爲此安裝了新版本的apsw。這個版本也運行緩慢。我在另一臺電腦上使用pythons built-int sqlite3嘗試了相同的代碼，並且它運行得很快（但是apsw速度很慢）。我也嘗試在我的電腦上安裝最新版本的pysqlite，但運行緩慢。如何診斷訪問sqlite數據庫緩慢的原因？
我絕對確定它不是模式的問題。
我現在的問題是，我該如何繼續診斷錯誤？
爲防萬一您可能忽略了這一點，請確保您使用的是the latest versions of both the pysqlite2 data base adapter and the sqlite3 library。鏈接的答案還顯示瞭如何確定您正在使用的每個版本，您可能想要添加到您的問題的數據。
我可以提供我的一個類似的體驗心得，但使用不同的平臺，即J.
有一些緩慢，而我把它精確定位到sqlite3_get_table功能。該函數爲每列返回一個指針，每個指向一個指針數組，每個指向一個以空字符結尾的字符串。如果函數的結果爲空，指針也可以爲null（比如Max數據集是一個空數據集，它將返回一個空指針，而不是指向null的指針，我討厭這個）。然後，J形成了可讀的地址（形成一個大型的地址矩陣，後跟一個0表示偏移量，-1表示長度，意思是第一個空），並循環遍歷每個地址，最後在表格中重新塑造其預期的列和行。
所以，有一個內存傳輸方面，以及實際的閱讀方面，從SQLite中獲取數據到另一個平臺。我發現這個通常很大的數據集不容易被J處理，這意味着它像所有字符串一樣笨重。另外還有那個討厭的空指針。
我能夠限制矩陣的修改足以優化功能。最終的優化是使用原始代碼來讀取一個內存地址（15!:1），而沒有正式命名的函數（memr），因爲使用memr意味着J必須解釋在每個內存讀取時memr意味着。
總之，如果python允許一些修改，也許你可以調整數據庫訪問以更好地滿足你的需求。我希望這可以幫助，但我沒有很高的期望...
我已經檢查過這個。這是最新版本。安裝pysqlite時，你可以真正告訴它下載並構建最新版本，這正是我所做的。 – 2010-10-01 19:28:56
如果您可以提供有關具體哪些平臺，哪些python版本，哪些pysqlite2版本，哪些apsw版本以及您正在使用哪個sqlite3版本的更多信息，它仍然很有用。在你的問題中有很多移動目標，很難知道從哪裏開始。 – 2010-10-01 22:00:20