對於資料庫分割槽欄位,索引欄位,基本資料型別如何在sql進行優化查詢

答案:我們應該在過濾條件使用順序調整成分割槽條件/索引條件/基本資料型別條件

資料庫分割槽

是一種物理資料庫設計技術，DBA和資料庫建模人員對其相當熟悉。雖然分割槽技術可以實現很多效果，但其主要目的是為了在特定的SQL操作中減少資料讀寫的總量以縮減響應時間。

分類

分割槽主要有兩種形式：//這裡一定要注意行和列的概念（row是行，column是列）

水平分割槽（Horizontal Partitioning）

這種形式分割槽是對錶的行進行分割槽，通過這樣的方式不同分組裡面的物理列分割的資料集得以組合，從而進行個體分割（單分割槽）或集體分割（1個或多個分割槽）。所有在表中定義的列在每個資料集中都能找到，所以表的特性依然得以保持。

舉個簡單例子：一個包含十年發票記錄的表可以被分割槽為十個不同的分割槽，每個分割槽包含的是其中一年的記錄。（朋奕注：這裡具體使用的分割槽方式我們後面再說，可以先說一點，一定要通過某個屬性列來分割，譬如這裡使用的列就是年份）

垂直分割槽（Vertical Partitioning）

這種分割槽方式一般來說是通過對錶的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分割槽，每個分割槽都包含了其中的列所對應的行。

舉個簡單例子：一個包含了大text和BLOB列的表，這些text和BLOB列又不經常被訪問，這時候就要把這些不經常使用的text和BLOB了劃分到另一個分割槽，在保證它們資料相關性的同時還能提高訪問速度。

在資料庫供應商開始在他們的資料庫引擎中建立分割槽（主要是水平分割槽）時，DBA和建模者必須設計好表的物理分割槽結構，不要儲存冗餘的資料（不同表中同時都包含父表中的資料）或相互聯結成一個邏輯父物件（通常是檢視）。這種做法會使水平分割槽的大部分功能失效，有時候也會對垂直分割槽產生影響。

優勢

效能的提升（Increased performance）

在掃描操作中，如果MySQL的優化器知道哪個分割槽中才包含特定查詢中需要的資料，它就能直接去掃描那些分割槽的資料，而不用浪費很多時間掃描不需要的地方了。需要舉個例子？好啊，百萬行的表劃分為10個分割槽，每個分割槽就包含十萬行資料，那麼查詢分割槽需要的時間僅僅是

對資料管理的簡化

分割槽技術可以讓DBA對資料的管理能力提升。通過優良的分割槽，DBA可以簡化特定資料操作的執行方式。例如：DBA在對某些分割槽的內容進行刪除的同時能保證餘下的分割槽的資料完整性(這是跟對錶的資料刪除這種大動作做比較的)。

此外分割槽是由MySQL系統直接管理的，DBA不需要手工的去劃分和維護。例如：這個例如沒意思，不講了，如果你是DBA，只要你劃分了分割槽，以後你就不用管了就是了。

索引

建立索引

##建立索引
# ALTER TABLE
ALTER TABLE table_name ADD INDEX index_name (column_list)
ALTER TABLE table_name ADD UNIQUE (column_list)
ALTER TABLE table_name ADD PRIMARY KEY (column_list)
# CREATE TABLE 不能用CREATE INDEX語句建立PRIMARY KEY索引
CREATE INDEX index_name ON table_name (column_list)
CREATE UNIQUE INDEX index_name ON table_name (column_list)
##刪除索引
DROP INDEX index_name ON talbe_name
ALTER TABLE table_name DROP INDEX index_name
ALTER TABLE table_name DROP PRIMARY KEY
##檢視索引
show index from tblname;
show keys from tblname;

什麼情況下使用索引

表的主關鍵字自動建立唯一索引 表的欄位唯一約束 直接條件查詢的欄位 查詢中與其它表關聯的欄位,欄位常常建立了外來鍵關係 查詢中排序的欄位 查詢中統計或分組統計的欄位

什麼情況下應不建或少建索引

表記錄太少

如果一個表只有5條記錄，採用索引去訪問記錄的話，那首先需訪問索引表，再通過索引表訪問資料表，一般索引表與資料表不在同一個資料塊，這種情況下ORACLE至少要往返讀取資料塊兩次。而不用索引的情況下ORACLE會將所有的資料一次讀出，處理速度顯然會比用索引快。

經常插入、刪除、修改的表

注意事項：

首先，應當考慮表空間和磁碟空間是否足夠。我們知道索引也是一種資料，在建立索引的時候勢必也會佔用大量表空間。因此在對一大表建立索引的時候首先應當考慮的是空間容量問題。其次，在對建立索引的時候要對錶進行加鎖，因此應當注意操作在業務空閒的時候進行。

效能調整方面： 首當其衝的考慮因素便是磁碟I/O。物理上，應當儘量把索引與資料分散到不同的磁碟上（不考慮陣列的情況）。邏輯上，資料表空間與索引表空間分開。這是在建索引時應當遵守的基本準則。 其次，我們知道，在建立索引的時候要對錶進行全表的掃描工作，因此，應當考慮調大初始化引數db_file_multiblock_read_count的值。一般設定為32或更大。再次，建立索引除了要進行全表掃描外同時還要對資料進行大量的排序操作，因此，應當調整排序區的大小。建立索引 對於查詢佔主要的應用來說，索引顯得尤為重要。很多時候效能問題很簡單的就是因為我們忘了新增索引而造成的，或者說沒有新增更為有效的索引導致。如果不加索引的話，那麼查詢任何哪怕只是一條特定的資料都會進行一次全表掃描，如果一張表的資料量很大而符合條件的結果又很少，那麼不加索引會引起致命的效能下降。但是也不是什麼情況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什麼優勢，還會影響到更新速度，這被稱為過度索引。複合索引 如果在area、age兩列上建立複合索引的話將帶來更高的效率。如果我們建立了(area, age,salary)的複合索引，那麼其實相當於建立了(area,age,salary)、(area,age)、(area)三個索引，這被稱為最佳左字首特性。因此我們在建立複合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。索引不會包含有NULL值的列 所以我們在資料庫設計時不要讓欄位的預設值為NULL。使用短索引 對串列進行索引，如果可能應該指定一個字首長度。例如，如果有一個CHAR(255)的列，如果在前10個或20個字元內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁碟空間和I/O操作。 排序的索引問題 mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此資料庫預設排序可以符合要求的情況下不要使用排序操作；儘量不要包含多個列的排序，如果需要最好給這些列建立複合索引。like語句操作 一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like “%aaa%” 不會使用索引而like “aaa%”可以使用索引。不要在列上進行運算 select * from users where YEAR(adddate)不使用NOT IN和操作 NOT IN操作都不會使用索引將進行全表掃描。NOT IN可以NOT EXISTS代替