比方說，我的表中有100行，有3列數字。我不需要所有的行，每次我獲取數據時只有大約一半的行。我只希望已更新的行作爲其餘的將是多餘的。基本問題：查詢數據和性能權衡
添加一個字段並給它一個日期時間字段以表示自從上次獲取它並更新（並將其用作SELECTing時的條件）時，它會更好嗎？或者，最好每次都下載所有數據（目前數據正在以JSON文件形式發回）。
這兩個選項之間的速度，帶寬使用情況和服務器CPU使用情況之間的折衷是什麼？前者是否比後者好？
Jens Struwe和roycl都是對的 - 但是當你問一個假設的問題時，你會得到正確的答案和矛盾。
如果只有一半數據是相關的，客戶端將如何確定要顯示哪些數據？如果決定可以通過軟件來完成，那麼在數據庫上執行它會更有效率 - 但它也更符合邏輯。
對於100行的表格，性能既不在這裏也不在那裏;可維護性和長期可升級性是一個更大的交易。大多數開發人員會期望邏輯數據庫設計，並且在數據庫而不是客戶端上完成排序/篩選。
總是（或者至少在可能的情況下）只選擇需要完成任務的數據。反之亦然：永遠不要選擇必須過濾掉的數據。結果是：爲更新添加時間戳字段，並僅選擇時間戳大於給定時間戳的那些行。
對於表中的100行和3列數字，如果服務器在少於幾十毫秒的時間內返回數據，那麼使用哪種方法並不重要。無論如何，如果頻繁查詢，行將全部存儲在內存中。它也使得你的json代碼更簡單，並且你的客戶端代碼變得笨拙（這可能是好的，並且更易於維護）。
如果您擁有數百萬行表，並且只需要一小部分數據，那麼您自然會想要限制返回集，並且最簡單的方法是使用SQL WHERE子句，例如WHERE dt_modified > my_timestamp。在適當優化的數據庫上，即使這個查詢可以在100ms以內。
這個問題可能與數據花費在網絡上的時間，客戶端花費多少時間來重新生成頁面，或者基於返回的數據來更新它有關。客戶端處理時間通常是這個過程中最慢的部分。只有在不同的瀏覽器和不同的網絡速度下進行測試才能找到服務器端微調，網絡修復（如壓縮數據壓縮）和優化JavaScript調用之間的最佳平衡。