只能說shit！剛剛寫了一篇mysql文章被鳥系統搞掛了，不想重寫了

摘自：http://www.blueshop.com.tw/board/show.asp?subcde=BRD20060111050846WJC&fumcde=FUM20041006152735ZFS

除此之外我可以跟你講是效能與儲存空間計算，SQL Server底層資料最小的儲存單位是Page(8k)，但是我們無法直接取用，我們能使用到的是資料表,Index，而它們是儲存在一個更大的單位extend(64K，等於8個Pages)，講這個幹嘛？

1. 因為Server磁碟在格式化時，NTFS有個選項配置單位大小4096Bytes,因此磁碟IO的二個Allocation剛好可以儲存一個Page，當你資料表Schema設計愈精簡，SQL Server的儲存讀取單位與NTFS磁碟IO愈能Match，這時就會效能最佳化；舉例來說身份證字號H120067600存nchar是10個字元，但由nvarchar會用掉20個字元，故可以理解若你每次讀取1000筆，nvarchar必須有更多的磁碟IO才能將資料讀完，同時也較浪費磁碟空間與電腦記憶體，故精明的DBA是會真實利用較為深入的知識來計算最佳化的Table Schema設計．
2. 另外一個是SQL Server必須維護相對的索引，包括索引控間及B-tree的維護，Nvarchar成本會比nchar來得高，最終也是效能問題

摘自：http://www.bigdbahead.com/?cat=4

盜圖就算連上傳都懶！shit！

摘自：
http://www.codecharge.com.tw/phpBB2/viewtopic.php?p=512
http://163.30.154.1/~dada/xoop/modules/newbb/viewtopic.php?topic_id=112&forum=6

調整：
table_cache = 192 <= 允許暫存在CACHE裡的TABLE數量
key_buffer = 384M <= 各個key可以使用的最大記憶體量

table_cache主要觀察Open_tables與Opened_tables，調到接近即可，1G的記憶體調整到128~256就好，太高也會降低效能
key_buffer主要觀察Key_read_requests與Key_reads，盡量增加到Key_read_requests為Key_reads的100倍，所謂的Key_reads是實際讀取硬碟量，Key_read_requests是要求量，記憶體越多代表越有機會直接從記憶體裡面讀取index，最直接的計算方法就是把你所有的index大小加起來，就是你該設定的key_buffer大小

指令：mysqladmin variables