如何在資料庫設計過程中優化大量資料？

資料庫優化說起來很簡單。

就像抽水的木桶一樣，瓶頸降低了。 首先，我們需要分析資料庫操作。

看看哪些有更多的等待時間，有哪些瓶頸。 喜歡 CPU？ io？很多硬解析？ 快取命中率低？ 然後分別處理它們。 從資料庫整體的角度來看，一般需要根據主機配置和實際使用情況，對SGA的容量進行一些配置調整。 增加資料檔案，分配表空間，正確分割槽，減少 I/O 熱點。

但是，大多數時候資料庫優化會體現在SQL上，而大部分有問題的資料庫都有異常的執行計畫，或者表設計不合理等，導致一些SQL語句的執行效率極低，影響了資料庫的效能。

儲存引擎的選擇; 表結構，包括索引、字段型別、表資料; SQL不能寫得太糟糕，至少通過解釋測試查詢來利用索引; 硬體優化，包括CPU、記憶體、磁碟IO等。

1.在硬體方面，伺服器應該不會太差，磁碟的讀寫效能會影響IO，可以認為使用好的硬碟，比如SSD

2.根據伺服器設定資料庫的引數，比如記憶體什麼的 3、在設計表時，應選擇字段型別並建立正確的索引 4.SQL優化，盡量使用索引，不要出現全表掃瞄等，網上有很多這樣的資訊，這些我就說大概這些了。

MRR 是針對特定查詢的 MySQL 優化。 假設某個查詢有乙個二級索引可用，讀取二級索引後，需要返回表中查詢當前二級索引上沒有的列值，因為二級索引上引用的主鍵值不一定是有序的，所以可能會造成大量隨機 ios。

如果要關閉 MRR 優化，則需要將優化器切換 MRR 設定為 OFF。

預設情況下，只有當優化器認為 MRR 可以帶來優化時才會採取 MRR，如果你想盡可能地採取 MRR，你需要將 MRR Cost Based 設定為 OFF，但最好不要這樣做，因為這確實是乙個陷阱，MRR 不一定一直都很好， 全表掃瞄有時會更快，如果您在這種情況下進行 MRR，它將完成。

MRR 對主鍵進行排序，以便磁碟上的後續操作是順序讀取，而不是隨機讀取。 從資源使用的角度來看，就是讓CPU和記憶體做更多的工作來交換磁碟的順序讀取。 但是，排序需要記憶體，並且此記憶體的大小由 read rnd buffer size 引數控制。

在資料庫優化方面，可以從以下幾個方面入手：

若要優化查詢以避免全表掃瞄，應首先考慮為 where 和 order by 中涉及的列編制索引。

應盡可能避免對 where 子句中的字段進行空值判斷。

在 where 子句中應盡可能避免使用 ！= 或 <>運算子。

查詢時，選擇後不要使用 *，手動新增欄位名稱。

關於軟體優化的簡單介紹：

SQL：索引調整：前提條件，資料量大，頻繁唯讀查詢SQL語言優化等查詢，連線表過多會影響資料庫效能設計合理，這意味著資料庫是按照資料庫規範化資料庫Oracle內部引數調整設計的：

調整檔案的環境引數。

DB 塊大小：資料庫中每個資料塊的大小，預設為 2048 位元組（2K），應增加到 4K 或 8K，大型資料庫常用 16K 和 32K，SGA 也應增加。

共享池大小：共享池大小是否合適，可以通過對資料庫的監控或一些SQL語句來獲取。

日誌緩衝區：為了減少 LGWR 和 DBWR 之間的衝突，大型資料庫的日誌緩衝區通常手動更大，通常為 2 到 3 M。

所有環境引數都可以通過系統的監控工具進行分析。

另外：適當地修改資料庫塊大小。

應用優化。

批量應用優化。

優化單個SQL語句。

摘要：良好的資料庫設計。

良好的建築設計。

良好的平台（硬體平台、網路平台）。

合理、充分的合理環境引數指標（作業系統環境引數、預言機環境引數）。

良好的DBA可以持續優化（管理）。

Oracle：海量資料庫。

SQL Server：適用於中小型企業的資料庫。

優化的概念太寬泛了，無法用一兩千字來完成。

Oracle 和 SQL Server 的區別其實並不大，都是商業資料庫，而且應用廣泛。

無非是 SQL Server 在過去兩年中得到了非常強大的更新，並且可程式設計性有所提高。

其實沒有太大的區別，用不同的需求，用不同的資料庫。

索引調整：前提條件、資料量大、唯讀查詢頻繁 語言優化。