查詢優化
在另一個問題中，他們告訴我 DBMS 的速度很大程度上取決於查詢的優化。有人知道這方面的好文件嗎？在學校我只學習了基礎知識。
例如，查找具有密碼的使用者的查詢。
我會從包含個人資訊或僅包含使用者名/密碼的表中獲取此資訊。
我的查詢看起來像：
SELECT username, password FROM tblUsers WHERE username = foo對此有什麼優化嗎？或者它只是在非常大的操作中，比如有很多 JOINS 和大量記錄？
編輯：上面的例子就是一個例子。我正在尋找有關查詢優化的文件；）
在關係數據庫中優化查詢的眾多方法中，索引是最好的起點。當您索引一列時，數據庫按排序順序儲存該列的記錄以提高搜尋速度。您為此付出的代價是額外的儲存成本和 INSERT/UPDATE/DELETE 語句的速度降低。
當您在無序列表中搜尋一個值時，最壞的情況是您必須查看每條記錄。如果您有 1,000,000 個項目的列表，則必須掃描所有 1,000,000 個項目。另一方面，如果列表是有序的，則可以使用二分查找代替，它可以在不超過 20 次查找中找到匹配的記錄。
想到這一點的最簡單方法是電話目錄，它以姓氏為索引。因此，如果您正在尋找“Wilson”，您可以跳過大部分頁面並直接進入“W”。另一方面，如果您正在尋找一個號碼來找出擁有該號碼的人的姓名，那麼您將被迫從頭開始，一次完成一個，這將是非常痛苦的.
現在想像一下，您有第二個按號碼排序的電話簿。您現在擁有兩倍多的書籍，這會佔用更多空間，但如果您通常根據電話號碼查找姓名，那麼這種權衡是非常值得的。
數據庫索引很像這樣。作為基本規則：
- 您經常包含在 WHERE/GROUP BY 子句中的索引列。
select * from t1 where poo = 'smelly'
select category, count(*) from t2 group by category
- 索引外鍵（引用其他表中的鍵的列）。例如：
select * from t1 join t2 on t1.lol = t2.rofl如果兩個表中的數據都足夠大，則外鍵索引
t1.lol可能會帶來顯著的收益。不應盲目地索引外鍵：與任何列一樣，不適當的索引沒有任何好處，有時會阻礙性能並導致死鎖等問題。
- 索引可以由多個列組成。事實上，如果SELECT 列表中的所有列都可以在索引中找到，則可以針對索引而不是表執行查詢。多列索引可以通過使用 AND（例如，
a = 'lol AND b = 'rofl'）的複合 WHERE 條件來利用，但不能使用 OR。如果前面的謂詞被重寫為，那麼列和a = 'lol OR b = 'rofl'上的兩個獨立索引會更好地為您服務。a``b這只是表面上的問題，但會給你帶來巨大的努力收益。