那麼，您希望幫助在 sql 中創建問題嗎？你真的得到了它！您即將學習一些可以在幾秒鐘內開始使用的最佳方法，這些方法肯定會在未來許多年里為您帶來回報。
好吧，我承認，我也是程序員。因此，我獲得了我的 MCDBA 來炫耀我認識到有關數據源的一兩件事。所以，最近我實際上做的 DBA 工作比表演工作還多。是的，我能聽到你在哭泣“叛徒！” 我實際上已經走到了黑暗的一面；“後端”。
這裡的好消息是我可以（用一句陳詞濫調的說法“）感受到你的痛苦。許多設計師將數據庫視為某種必需的邪惡。根據我的經驗，普通程序員只知道足夠的 SQL 來插入、更新和刪除數據源中的單個記錄。讓 DBA 來處理這些粗糙的事情。不幸的是，許多開發人員無法接觸到 DBA（至少不是一個樂於與他們打交道的人），因此必須自己練習 SQL。同樣，想像一下，當你有能力讓“傻點走得更快”時，你一定會獲得同輩的尊重，你一定會獲得豐厚的加薪，以及獲得聖徒提名。
因此，以下是我實際發現的 3 大交易，平均“喬設計師”可以實施以提高他們的詢問反應時間。
一：開發中的任何工作！
首先，讓我們跳出框框思考一下。我知道我說過我將提供有關如何使您的查詢更快的提示……和我一樣。但是，這可能有點偏離常規。然而，這不是一個很好的提示嗎？你目前還沒有聽過一百遍的東西？
這就是背景：應用程序在罐子裡，工作得很好，現在也開始了。幾天之內，您開始聽到有人說應用程序的某些部分運行緩慢。這些抱怨很快就成為了幫助票。這些援助票很快最終成為與負責人和個人的會議。這些會議往往會成為酒癮……你明白了。
這種不利的情況也經常發生，並且有一個相對簡單的解決方案。您會看到，由於您的開發數據庫中有相當多的記錄，因此每件小事都在您的發展環境中始終表現良好！當然，如果我的主表中只有 30 個文檔，我的應用程序肯定也會出色地工作！一旦進入現實生活，輸入或導入幾十萬甚至無數的記錄，性能調整的需求就成為一個重要的表象。
服務很簡單；在您的晉升環境中開發相同數量的記錄，就像您在運營的第一年肯定會預期的那樣。如果您有可導入的數據（狀態、來自傳統系統或第 3 方提要），它們會將它們泵入。如果您沒有，那麼有大量的開放資源能量來創建模擬數據，這些數據將密切適應您的實際信息。目前，當您最初編寫查詢時，如果您需要專注於特定查詢以防止未來的頭痛和諮詢費用，您將擁有一個非常好的概念。
B) 了解您的索引。
許多開發人員完全忽略了索引。有幾個不理解它們。索引只是對數據源表中信息SQL 開發的製表。在創建應用程序時，打印出由索引組成的數據源架構，以便您在編寫查詢時了解它們是什麼。如果缺少適當的索引，請讓具有索引經驗的人開發它（無論是您、牆壁另一邊的程序員還是 DBA）。
下面是效果。假設您正在編寫一個呼叫管理系統。您可能會有一張帶有名字、姓氏等的表格。為簡單起見，我們將在一張帶有明顯地區名稱的大表格中完成這項工作。您很可能會編寫一個類似於以下內容的查詢：。
選擇 Person_ID、Name_First、Name_Last。
來自 Person_Data。
其中 Name_Last = @NameLast。
並且 Name_First = @NameFirst。
如果有 100 行，這肯定會立即起作用。儘管如此，隨著您的數據源增長到數以千計的文檔，查詢將減少，在某些時候會出現秒數變化。如果您只是簡單地添加包含 Name_Last 和 Name_First 列的索引，那麼在應用程序的整個生命週期中，您肯定會有基本的即時返回時間。