Mysql
如何針對任意使用者進行的查詢優化表？
假設您有一個大型數據庫表，並且您希望允許使用者使用 API 查詢它，使用幾個不同的過濾器和排序選項，當然還支持分頁。
優化此類查詢的最佳策略是什麼？為每種可能的選項組合創建索引似乎不切實際。
有關我想到的真實範例，請參閱 Shopify 中的此產品搜尋請求。大公司如何處理具有 20 種不同過濾器和 10 種不同排序選項的此類查詢，對可能有數十萬行的表進行處理？
在我們的特定案例中，我們在 AWS RDS 中使用 MySQL。
謝謝！
您無法針對所有內容進行優化。
這實際上是優化的定義，您正在選擇一種類型的查詢，它比其他查詢具有一些優勢。
如果所有查詢都“優化”，那麼它們都沒有任何特殊優勢。不知何故，它們都更快。
聽起來您只需要一台速度更快的電腦。
大公司如何做到這一點？多種解決方案：
- 真的在警告大電腦。
- 以不同的方式記憶體數據，因此在大多數情況下根本不需要執行查詢。
- 數據的多個副本，以不同的方式進行索引，或以不同的方式進行非規範化。因此，應用程式碼需要知道如何將某些查詢與正確的數據副本相匹配。
或者對所有副本啟動查詢，並且以最快速度返回的那個成為響應。
你優化它們就像優化其他任何東西一樣。
不要害怕在一張表上有多個索引，只要它們能解決問題，那麼它們可能值得擁有。考慮允許哪些查詢，哪些過濾器將是常見的，並負責查詢的大部分選擇性。例如，如果您有一個客戶表，並且您正在尋找標題是“先生”而姓氏是“Sayer”的地方，那麼您在這裡的主要選擇將由姓氏驅動 - 包括索引中的標題不會是特別有用。如果您知道您的表以及它們所代表的內容，那麼很容易確定哪些列將用於驅動您的查詢。
請記住，查詢也將由您的應用程序確定 - 您可以輕鬆擁有它，以便必須過濾某些列。
按使用者確定的列排序通常要麼是主鍵（如果它是某個序列），要麼是一個非常明顯的日期列。如果您要索引的列可能無法將表選擇性降低到足夠低，那麼將按列的順序添加到末尾是一種明智的策略