外部聯結(Outer Join)和笛卡兒積(Cartesian Product)
在這個關於「常見的 SQL 查詢錯誤」的系列中,我們一直在探索看似直觀的 SQL 查詢建構方法如何導致反模式,從而導致錯誤的結果和/或效能降低。上週,我們暫停了這個系列,討論了 SQL 中的述詞。在本期文章中,我們將學習它們的位置如何對查詢執行產生負面影響,尤其是在外部聯結中。
第 2 部分:非 SARGable 查詢條件
和大多數程式設計師一樣,資料庫開發人員或多或少傾向於撰寫直接翻譯指定請求的程式碼。大多數程式設計語言(包括 SQL)被設計為人們看得懂的,這也導致了一個問題。為什麼會有問題?所有程式設計語言都能比其他語言更快地執行某些作業。在關聯式資料庫中,查詢最佳化工具用於分析 SQL 查詢,並判斷稱為查詢計劃的高效執行機制。最佳化工具能為每個查詢產生一個或多個查詢計劃,每個查詢計劃代表一種可能的查詢執行方式。然後選取最有效的査詢計劃,並利用它來執行査詢。事實證明,模仿請求語言的 SQL 甚少是最有效的方法。
在常見的 SQL 查詢錯誤系列的這一部分中,我們將探討一個撰寫得不好的 SQL 陳述式的範例,並以提高效率的方式重寫它。
NOT IN 與 NOT EXISTS
在程式設計界,「反面模式(anti-pattern)」是一個常用術語。它指的是解決經常出現的問題的方法,而這方法不僅無效,而且有可能適得其反。這個術語最初是由電腦程式師 Andrew Koenig 於 1995 年在其著作《設計模式》中創造的,作為被認為既可靠又有效的設計模式的反義詞。
根據日期查詢
在 MySQL 中的日期和時間系列的最後一部分中,我們將透過撰寫 SELECT 查詢來取得資料中與日期相關的細節,從而將迄今為止所學到的一切付諸實踐。
Navicat 文章
頻道記錄
分享
部落格封存檔
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)