1 回答

TA貢獻1827條經驗 獲得超4個贊
滾動瀏覽可能有數千條記錄
編寫查詢,可能是臨時的,以過濾出更少的記錄。如果管理員需要滾動瀏覽超過幾十條記錄,那么你(和數據庫)就讓他失望了。
分頁——不要使用OFFSET
; “記住你離開的地方”:http: //mysql.rjweb.org/doc.php/pagination
分區——否;你還沒有提出一個它會受益的案例。你可以簡單地說WHERE name LIKE 'J%'
or WHERE name >= 'P' AND name < 'T'
(for p,q,r,s)并INDEX
name
以;開頭 但我懷疑這是否真的對管理員有幫助。
“一個不斷向下鉆取的遞歸函數”——這就是 BTree 索引已經為您做的事情。簡單地做WHERE name > $leftoff ORDER BY name LIMIT 20
。即,LIMIT
用于桶大?。煌瑫r不要打擾預定義桶邊界。
“潛在內存使用”——讓數據庫擁有大部分可用內存通常更好。
1 表 vs 3 -- 請詳細說明這些表中的內容。
搜索中
正如其他人所說,使用某種搜索機制可能是找到所需記錄的最快方法。不要讓管理員滾動瀏覽數千行。
提供一個表格,其中包含一項或多項內容供管理員填寫
完整的用戶名。(問題:拼寫錯誤/不知道確切的拼寫)
通配符部分名稱。例子:'段%'; 然后顯示所有以 Dan 開頭的用戶名。
大量的超鏈接列表,每個用戶一個。最多可達幾千個;我會建議不要這樣做。
用戶的一個屬性——開始日期、無活動等等。然后搜索該屬性。
對于這些部分情況,拒絕顯示超過100個用戶名;如果不止于此,請要求管理員提供更多詳細信息。不要為分頁增加的復雜性而煩惱。
我已經實施了各種這些和其他機制。回想起來,我唯一一次對幾十個項目使用分頁是在我需要對所有項目采取行動時。示例:從旅行中的一千張圖片中挑選一張放入“相冊”。這包括看每張照片足夠長的時間來挑選或拒絕每一張。此外,我使用 AJAX 來單擊一次所需的所有操作。
- 1 回答
- 0 關注
- 127 瀏覽
添加回答
舉報