【正文】 參考。什么時(shí)候離光明最近？那就是你覺得黑暗太黑的時(shí)候。我不知道年少輕狂，我只知道勝者為王。歡迎您的光臨，！希望您提出您寶貴的意見，你的意見是我進(jìn)步的動(dòng)力。 我以前看到過很多項(xiàng)目，數(shù)據(jù)庫系統(tǒng)只是被純粹的當(dāng)作了一個(gè)存儲(chǔ)數(shù)據(jù)的地方，建完表能增刪改查就萬事大吉了，有的連索引都沒有，對于數(shù)據(jù)庫的建立也很不嚴(yán)謹(jǐn)，更談不上管理，雖然很多人認(rèn)為數(shù)據(jù)庫的管理是DBA的事情，但是我想作為一個(gè)技術(shù)人員，加深對數(shù)據(jù)庫的了解是絕對沒有壞處的，開發(fā)大型的系統(tǒng)，數(shù)據(jù)庫肯定是非常重要的。在oracle里，分區(qū)的概念是比較多的，包括對索引的分區(qū)都會(huì)有很多介紹，如散列分區(qū)，混合分區(qū)，局部索引，全局索引，原理上是差不多的。對于索引，sqlserver里有索引分區(qū)，如果索引分區(qū)和表分區(qū)對齊的話，就是說和表一樣使用了相同的分區(qū)函數(shù)和相同的分區(qū)架構(gòu)，那么對于索引的查找，就不是對整個(gè)索引的查找了，而是先判斷在哪個(gè)索引分區(qū)，然后再取查找該索引值，然后找到數(shù)據(jù)，這樣就會(huì)節(jié)省很多時(shí)間。分區(qū)總結(jié)20100901 11:59:39。CHECK ([emdate] = 39。[emdate] [datetime] NULL如果要限制的emdate的值的范圍，則必須給它加上約束，如只允許emdate的值從2002年9月1日到2010年9月1日，)[fax] [char] (15) COLLATE Chinese_PRC_CI_AS NULL ,傳真[pos] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,郵編[sex] [char] (10) COLLATE Chinese_PRC_CI_AS NULL ,性別[age] [int] NULL ,年齡[id] [bigint] NOT NULL , 記錄的id范圍分區(qū)始終只映射到表中的一列，此列應(yīng)與分區(qū)函數(shù)中定義的邊界條件的數(shù)據(jù)類型相匹配。表定義應(yīng)使用的架構(gòu)，而架構(gòu)又定義函數(shù)。TO ([person001], [person002], [person003], [person004], [PRIMARY])AS因?yàn)榇朔謪^(qū)永遠(yuǎn)不包含數(shù)據(jù)，所以不需要指定特殊的位置定義分區(qū)架構(gòu)時(shí)，即使多個(gè)分區(qū)位于同一個(gè)文件組中，也必須為每個(gè)分區(qū)指定一個(gè)文件組。創(chuàng)建分區(qū)架構(gòu)分區(qū)4：=20070930,20090930分區(qū)2：=20030930,20050930如果當(dāng)前選項(xiàng)是RIGHT,則表示：分區(qū)4：20070930,=20090930分區(qū)2：20030930,=20050930如當(dāng)前選項(xiàng)是LEFT，則表示：上面的分區(qū)函數(shù)創(chuàng)建了5個(gè)分區(qū)，并且定義了分區(qū)列的數(shù)據(jù)類型為datetime,因?yàn)榉謪^(qū)的標(biāo)準(zhǔn)要建在表的某一列上，在此定義，分區(qū)列必須是日期時(shí)間型。2009093039。,39。2005093039。,RANGE LEFT FOR VALUES (39。CREATE PARTITION FUNCTION personRangePFN(datetime)既然分區(qū)，那么就應(yīng)該有一個(gè)分區(qū)的標(biāo)準(zhǔn)，就是說數(shù)據(jù)將以什么標(biāo)準(zhǔn)來分區(qū)，分區(qū)函數(shù)就是做這件事情的，它定義數(shù)據(jù)劃分的標(biāo)準(zhǔn)，對表進(jìn)行邏輯上的劃分。如上，為文件組添加了一個(gè)數(shù)據(jù)文件FILEGROWTH = 5MB)SIZE = 5MB,C:\ipanel\39。,(NAME = N39。ALTER DATABASE ipanel現(xiàn)在為ipanel數(shù)據(jù)庫創(chuàng)建了一個(gè)名為person_fg的文件組。為數(shù)據(jù)庫添加文件組，這個(gè)文件組分布存儲(chǔ)person表的數(shù)據(jù)：下面一步一步來，mon創(chuàng)建文件組 分區(qū)是比較復(fù)雜的，以分區(qū)的對象來分類的話，則分為兩種，表分區(qū)和索引分區(qū)。 對于一些超大型的表，分區(qū)是非常有用的。5:sqlserver的分區(qū)看來，用union在通常情況下比用or的效率要高的多。掃描計(jì)數(shù) 2，邏輯讀 59810 次，物理讀 0 次，預(yù)讀 0 次。select id,name,dept,emdate from person where emdate39。(2):select id,name,dept,emdate from person where name=39。次。用時(shí)：85626ms。2007060439。王小雪39。 很多資料都推薦用union來代替or。7:union并不絕對比or的執(zhí)行效率高掃描計(jì)數(shù) 1，邏輯讀 29905 次，物理讀 0 次，預(yù)讀 0 次。select id,name,dept,emdate from person where name like 39。掃描計(jì)數(shù) 1，邏輯讀 29905 次，物理讀 0 次，預(yù)讀 0 次。,name)0select id,name,dept,emdate from person where charindex(39。 前面，我們談到，如果在LIKE前面加上通配符%，那么將會(huì)引起全表掃描，所以其執(zhí)行效率是低下的。6:用函數(shù)charindex()和前面加通配符%的LIKE執(zhí)行效率一樣我們從此可以看到用exists和用in的執(zhí)行效率是一樣的。掃描計(jì)數(shù) 1，邏輯讀 2 次，物理讀 0 次，預(yù)讀 0 次。表 39。掃描計(jì)數(shù) 18，邏輯讀 56 次，物理讀 0 次，預(yù)讀 0 次。表 39。（2）select title,price from titles where exists (select * from sales where = and qty30)掃描計(jì)數(shù) 1，邏輯讀 2 次，物理讀 0 次，預(yù)讀 0 次。表 39。掃描計(jì)數(shù) 18，邏輯讀 56 次，物理讀 0 次，預(yù)讀 0 次。表 39。（1）select title,price from titles where title_id in (select title_id from sales where qty30)運(yùn)行前我們可以把SQL SERVER的statistics I/O狀態(tài)打開。但事實(shí)上，我試驗(yàn)了一下，發(fā)現(xiàn)二者無論是前面帶不帶not，二者之間的執(zhí)行效率都是一樣的。5:exists 和 in 的執(zhí)行效率是一樣的所花時(shí)間:5326ms,聶海39。王小雪39。所花時(shí)間:5310ms,聶海39。王小雪39。沒有聚集索引 or name=39。select id,name,dept,emdate from person where name=39。),39。select id,name,dept,emdate from person where name in(39。4:IN 的作用是否相當(dāng)與ORABS(價(jià)格)5000 ,Name like ‘%三’ ，有些表達(dá)式，如： WHERE 價(jià)格*25000 ,SQL SERVER也會(huì)認(rèn)為是SARG，SQL SERVER會(huì)將此式轉(zhuǎn)化為： WHERE 價(jià)格2500/2 .但不推薦這樣使用，因?yàn)橛袝r(shí)SQL SERVER不能保證這種轉(zhuǎn)化與原始表達(dá)式是完全等價(jià)的。不滿足SARG形式的語句最典型的情況就是包括非操作符的語句，如：NOT、!=、!、!、NOT EXISTS、NOT IN、NOT LIKE等，另外還有函數(shù)。由上可以得出結(jié)論,在用到or的時(shí)候，如果有聚集索引,就不會(huì)引起全表掃描,沒有聚集索引,就會(huì)引起全表掃描，所以說，只要用or就會(huì)引起全表掃描是片面的，不正確的。在有聚集索引的情況下(無論聚集索引建在哪些字段上)2007060839。王小雪39。如name=’王小雪’ and emdate’20070110’不會(huì)全表掃描,而有很多資料上說or會(huì)引起全表掃描。由以上數(shù)據(jù)可以看到，將匹配符號放在被查詢字段的前面，索引根本就不會(huì)發(fā)生作用，所以這也是要注意的地方，如果不會(huì)用到，最好少用select id,name,dept,emdate from person where name like 39。用時(shí) 3673毫秒%小雪39。對name進(jìn)行非聚集索引select id,name,dept,emdate from person where name like 39。 如以下查詢?nèi)纾簄ame like ‘王%’ ，這就屬于SARG介紹完SARG后，我們來總結(jié)一下使用SARG以及在實(shí)踐中遇到的和某些資料上結(jié)論不同的經(jīng)驗(yàn)：所以一個(gè)索引對于不滿足SARG形式的表達(dá)式來說是無用的。Name=’張三’ ，價(jià)格5000 ，5000價(jià)格 ，Name=’張三’ and 價(jià)格5000列名可以出現(xiàn)在操作符的一邊，而常數(shù)或變量出現(xiàn)在操作符的另一邊。形式如下：如果一個(gè)階段可以被用作一個(gè)掃描參數(shù)（SARG），那么就稱之為可優(yōu)化的，并且可以利用索引快速獲得所需數(shù)據(jù)。 雖然查詢優(yōu)化器可以根據(jù)where子句自動(dòng)的進(jìn)行查詢優(yōu)化，但大家仍然有必要了解一下“查詢優(yōu)化器”的工作原理，如非這樣，有時(shí)查詢優(yōu)化器就會(huì)不按照您的本意進(jìn)行快速查詢。事實(shí)上，這樣的擔(dān)心是不必要的。王小雪39。 用時(shí)：1173毫秒select * from table1 where id 10