❶ 如何優化資料庫
設計資料庫要滿足三大範式：第一範式：
1、內容相似的數據列必須消除(消除的辦法就是再創建一個數據表來存放他們，建立關聯關系)
2、必須為每一組相關數據分別創建一個表
3、每條數據記錄必須用一個主鍵來標示
第二範式：
1、只要數據列裡面的內容出現重復，就意味著應該把表拆分為多個表
2、拆分形成的表必須用外鍵關聯起來。
第三範式：
1、與主鍵沒有直接關系的數據列必須消除(消除的辦法就是再創建一個表來存放他們)
❷ 資料庫怎麼優化sql怎麼優化
1 避免無計劃的全表掃描
如下情況進行全表掃描：
- 該表無索引
- 對返回的行無任何限制條件（無Where子句）
- 對於索引主列（索引的第一列）無限制條件
- 對索引主列的條件含在表達式中
- 對索引主列的限制條件是is (not) null或!=
- 對索引主列的限制條件是like操作且值是一個bind variable或%打頭的值
2 只使用選擇性索引
索引的選擇性是指索引列中不同值得數目和標志中記錄數的比，選擇性最好的是非空列的唯一索引為1.0。
復合索引中列的次序的問題：
1 在限定條件里最頻繁使用的列應該是主列
2 最具有選擇性的列（即最清晰的列）應該是主列
如果1和2 不一致，可以考慮建立多個索引。
在復合索引和多個單個索引中作選擇：
考慮選擇性 考慮讀取索引的次數 考慮AND-EQUAL操作
3 管理多表連接（Nested Loops, Merge Joins和Hash Joins） 優化聯接操作
Merge Joins是集合操作 Nested Loops和Hash Joins是記錄操作返回第一批記錄迅速
Merge Joins的操作適用於批處理操作，巨大表 和遠程查詢
1全表掃描 --〉 2排序 --〉3比較和合並 性能開銷主要在前兩步
適用全表掃描的情形，都適用Merge Joins操作（比Nested Loops有效）。
改善1的效率： 優化I/O， 提高使用ORACLE多塊讀的能力， 使用並行查詢的選項
改善1的效率：提高Sort_Area_Size的值， 使用Sort Direct Writes，為臨時段提供專用表空間
4 管理包含視圖的SQL語句
優化器執行包含視圖的SQL語句有兩種方法：
- 先執行視圖，完成全部的結果集，然後用其餘的查詢條件作過濾器執行查詢
- 將視圖文本集成到查詢里去
含有group by子句的視圖不能被集成到一個大的查詢中去。
在視圖中使用union，不阻止視圖的SQL集成到查詢的語法中去。
5 優化子查詢
6 使用復合Keys/Star查詢
7 恰當地索引Connect By操作
8 限制對遠程表的訪問
9 管理非常巨大的表的訪問
- 管理數據接近(proximity) 記錄在表中的存放按對表的范圍掃描中最長使用的列排序 按次序存儲數據有助於范圍掃描，尤其是對大表。
- 避免沒有幫助的索引掃描 當返回的數據集合較大時，使用索引對SGA的數據塊緩存佔用較大，影響其他用戶；全表掃描還能從ORACLE的多塊讀取機制和「一致性獲取/每塊」特性中受益。
- 創建充分索引的表 使訪問索引能夠讀取較全面的數據 建立僅主列不同的多個索引
- 創建hash簇
- 創建分割表和視圖
- 使用並行選項
10 使用Union All 而不是Union
UNION ALL操作不包括Sort Unique操作，第一行檢索的響應速度快，多數情況下不用臨時段完成操作，
UNION ALL建立的視圖用在查詢里可以集成到查詢的語法中去，提高效率
11 避免在SQL里使用PL/SQL功能調用
12 綁定變數(Bind Variable)的使用管理
使用Bind Variable和Execute using方式
將like :name ||』%』 改寫成 between :name and :name || char(225), 已避免進行全表掃描，而是使用索引。
13 回訪優化進程
數據變化後，重新考察優化情況
❸ 有哪些常見的資料庫優化方法
調整數據結構的設計。調整應用程序結構設計。
數據是指對客觀事件進行記錄並可以鑒別的符號，是對客觀事物的性質、狀態以及相互關系等進行記載的物理符號或這些物理符號的組合。它是可識別的、抽象的符號。
它不僅指狹義上的數字，還可以是具有一定意義的文字、字母、數字元號的組合、圖形、圖像、視頻、音頻等，也是客觀事物的屬性、數量、位置及其相互關系的抽象表示。例如，「0、1、2…」、「陰、雨、下降、氣溫」、「學生的檔案記錄、貨物的運輸情況」等都是數據。數據經過加工後就成為信息。
在計算機科學中，數據是所有能輸入計算機並被計算機程序處理的符號的介質的總稱，是用於輸入電子計算機進行處理，具有一定意義的數字、字母、符號和模擬量等的通稱。計算機存儲和處理的對象十分廣泛，表示這些對象的數據也隨之變得越來越復雜。
❹ mysql資料庫怎麼優化，有幾方面的優化
在開始演示之前，我們先介紹下兩個概念。
概念一，數據的可選擇性基數，也就是常說的cardinality值。
查詢優化器在生成各種執行計劃之前，得先從統計信息中取得相關數據，這樣才能估算每步操作所涉及到的記錄數，而這個相關數據就是cardinality。簡單來說，就是每個值在每個欄位中的唯一值分布狀態。
比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數可以是100個，也可以是1個，當然也可以是1到100之間的任何一個數字。這里唯一值越的多少，就是這個列的可選擇基數。
那看到這里我們就明白了，為什麼要在基數高的欄位上建立索引，而基數低的的欄位建立索引反而沒有全表掃描來的快。當然這個只是一方面，至於更深入的探討就不在我這篇探討的范圍了。
概念二，關於HINT的使用。
這里我來說下HINT是什麼，在什麼時候用。
HINT簡單來說就是在某些特定的場景下人工協助MySQL優化器的工作，使她生成最優的執行計劃。一般來說，優化器的執行計劃都是最優化的，不過在某些特定場景下，執行計劃可能不是最優化。
比如：表t1經過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經很不準確了，這時候剛好執行了一條SQL，那麼有可能這條SQL的執行計劃就不是最優的。為什麼說有可能呢？
來看下具體演示
譬如，以下兩條SQL，
A：
- select * from t1 where f1 = 20;
B：
- select * from t1 where f1 = 30;
- mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)
- mysql> select count(*) from t1;+----------+| count(*) |+----------+| 32768 |+----------+1 row in set (0.01 sec)
SQL C：
- select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;
SQL D：
- select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;
- mysql> explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "3243.65" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_proced_per_join": 115, "filtered": "0.36", "cost_info": { "read_cost": "3232.07", "eval_cost": "11.58", "prefix_cost": "3243.65", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
- mysql> explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "441.09" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_proced_per_join": 1103, "filtered": "100.00", "cost_info": { "read_cost": "330.79", "eval_cost": "110.30", "prefix_cost": "441.09", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
不加HINT，
- mysql> explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "534.34" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_proced_per_join": 0, "filtered": "0.07", "cost_info": { "read_cost": "478.84", "eval_cost": "0.04", "prefix_cost": "534.34", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))" } }}1 row in set, 1 warning (0.00 sec)
加了HINT，
- mysql> explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "5.23" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_proced_per_join": 1, "filtered": "100.00", "cost_info": { "read_cost": "5.13", "eval_cost": "0.10", "prefix_cost": "5.23", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))" } }}1 row in set, 1 warning (0.00 sec)
如果f1的值剛好頻繁更新的值為30，並且沒有達到MySQL自動更新cardinality值的臨界值或者說用戶設置了手動更新又或者用戶減少了sample page等等，那麼對這兩條語句來說，可能不準確的就是B了。
這里順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。
那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。
示例表結構：
表記錄數：
這里我們兩條經典的SQL：
表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。
那我們來看SQL C的查詢計劃。
顯然，沒有用到任何索引，掃描的行數為32034，cost為3243.65。
我們加上hint給相同的查詢，再次看看查詢計劃。
這個時候用到了index_merge,union了三個列。掃描的行數為1103，cost為441.09，明顯比之前的快了好幾倍。
我們再看下SQL D的計劃：
對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。
總結下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。
❺ 簡單易用的資料庫哪個比較好
1.數據量太大，比如上億，就用oracle，優點上億數據對Oracle來說輕飄飄的，也不用太多優化配置，缺點安裝比較麻煩，上手比較慢。
2.數據量較大，比如千萬級，用postgresql，它號稱對標Oracle，處理千萬級數據還是可以的，也是易學易用。
3.數據量一般，比如百萬級，用mysql，這個級別的數據量mysql處理還是比較快的。
4.數據量較小，比如十萬以下，sqlite、access都可以。
上面是基於單表操作的數據量，你看著選。
簡單易用的資料庫哪個比較好？這個要具體看你的用途，如果數據量比較少（10萬左右），追求簡約簡單，免費開源的sqlite就行，如果數據量比較多，考慮到高並發、分布式，可以使用專業的mysql、postgresql，下面我分別簡單介紹一下，感興趣的朋友可以嘗試一下：
小巧靈活sqlite這是基於c語言開發的一個輕量級關系型資料庫，短小精悍、免費開源，個人使用無需繁瑣的配置，只需一個簡單的運行庫便可直接使用，針對各種編程語言都提供了豐富的API介面， java、 python、c#等都可輕松操作，如果你存儲數據量不多，只是本地簡單的操作（讀多寫少），可以使用一下這個資料庫，佔用內存非常少，輕便靈活，當然，在高並發、數據量大的情況下就不合適了：
專業強大mysql
這是目前應該廣泛使用的一個關系型資料庫，免費開源跨平台，在信息系統開發方面一直占據著主力位置，如果你從事於web開發或者網站後台建設，那麼這個資料庫一定非常熟悉，支持高並發、分布式，存儲數據量相對於sqlite來說，更多也更安全，索引、觸發器、存儲過程等功能非常不錯，支持數據導入導出、恢復備份，只要你熟悉一下基本使用過程，很快就能掌握和運用：
免費開源postgresql
這是加州大學計算機系開發的一個對象-關系型資料庫（自由軟體），免費、開源、跨平台，支持流計算、全文檢索、圖式搜索、並行計算、存儲過程、空間數據、K-V類型，相比較mysql來說，在復雜查詢、高並發下更穩定、性能更優越，可擴展性、可維護性非常不錯，但也有劣勢，例如新舊版本不分離存儲，沒有Coverage index scan等，總體使用效果來說還不錯：
當然，除了以上3個資料庫，還有許多其他資料庫，像mssql、oracle等也都非常不錯，對於存儲和處理數據來說綽綽有餘，只要你熟悉一下基本使用過程，很快就能入門的，網上也有相關教程和資料，介紹的非常詳細，感興趣的話，可以搜一下，希望以上分享的內容能對你有所幫助吧，也歡迎大家評論、留言進行補充。
最符合初學者理解和入門的是Access，因為它和Excel本來就是一個套件，相互轉化容易，復制粘貼即可，非常好理解庫、表、欄位、鍵的概念。
如果數據量不大，強烈推薦試試Filemaker，腳本化編程，自由定製輸入界面、工作流程，非常便捷高效。
最近殺出來的airtable，更是簡單高效，界面美觀，操作與電子表格相當，發展勢頭也非常迅猛。
二者側重點有所不同，用戶可根據需要選擇
作為一個軟體開發人員，長期需要和資料庫打交道，個人更加青睞於MySQL。雖然可能基於你的Excel原因，有些人會建議你使用Access資料庫，但是基於我個人的 意見，我並不建議你那樣做。採用MySql的具體理由如下：
1.MySQL具有普遍性，在國內的環境中，絕大多數的互聯網企業採用的是MySQL。有了廣大的用戶基礎後，針對於各種問題網上也能更好地找到解決方案。
2.MySQL相對於Oracle而言，更加輕量化，針對於從Excel量級的數據，沒必要使用Oracle。同時MySQL是完全免費的，不用擔心版權及費用問題，無論對個人還是對預算有限的企業而言都是很好的選擇。
3.MySQL高度兼容標准SQL，這對於以後遷移到其他資料庫而言，也能很大程度地降低學習成本。
希望我的回答能夠對你有所幫助！！！[耶][耶][耶]
Excel辦公確實便利，可以做一些簡單的數據分析，但涉及大量復雜的數據運算，就會遇到和題主一樣的問題，運算速度慢，如果主機性能不是很好，還有可能面臨電腦死機，數據丟失等問題。
遇到這種情況，我們該如何解決呢？資料庫的重要性顯而易見！
現在， 我將用3分鍾的時間，與您探討該選擇何種資料庫，以及選擇它的理由，是否有更優的解決方案呢？
MySQL資料庫，90%的企業都會選擇它資料庫選得好，企業的數據安全，資產安全，也就得到了保障。那麼該如何選擇資料庫呢？這個跟你的業務量和業務服務行業，密不可分。
如果你只是上班打卡，用SQL server就可以了；
如果你要儲存會話信息，用戶配置信息，購物車數據，建議使用NoSQL資料庫；
不過90%的企業或個人，首選資料庫都是MySQL資料庫。
為什麼這么說？因為，它集 低成本、高可用、可靠性強、易用性強、體積小、速度快開放源碼 等特性於一身，所以在金融、財務、網站、 數據處理 等應用領域，它占據著獨一無二的優勢。
這也是幾乎所有企業都選擇它，來存儲數據的原因。
加之MySQL資料庫，支持多種存儲引擎，支持大型資料庫，可以處理成千上萬條記錄，還提供用於管理、檢查、優化資料庫操作的工具。
因而，MySQL尤其受個人，以及中小企業的推崇。
雖然MySQL資料庫簡單易用，但我還是不會部署該怎麼辦？別擔心，現在市面上已經出現了，一種自帶資料庫的新型辦公軟體。
比如說，雲表企業應用平台，一款兼容excel功能，但功能更為強大的辦公軟體，它就內嵌了MySQL資料庫。 （文末有免費獲取方式）
雲表內嵌的MySQL資料庫，有何優點？1. 性能更加優化，更加兼容系統。因為雲表的研發人員，時刻更新維護MySQL資料庫。
2. 省去自己手動部署的麻煩。但如果你熟悉部署資料庫，想把資料庫改成Oracle或SQL server等資料庫，也可以設置。（不過，我建議IT小白還是 「拿來即用」 就好）
3. 快速實時計算。數據分析實時交互，完全滿足管理決策中的臨時性分析，多變的業務需求，以及頻繁的結果刷新。
4. 通過自帶的內存計算引擎，無需事先建立CUBE，IT部門將告別報表延時報表分析，億級數據秒級響應。
內嵌的MySQL資料庫是否可靠雲表不僅是一款辦公軟體，同時還是一款開發工具。
通過它，你將解決以下問題：
復雜的數據運算，精確到行列的許可權管控，以及工作流，海量用戶同時在線辦公，數據透視，製作像銷售單，洽談合同等表單報表，一份製作，即可重復錄用......
你還可以通過它，與電子稱、地磅等進行對接，與用友金蝶等三方系統集成，生成條形碼，掃碼出入庫，生成移動端APP...... 基本上業務所需的功能，你都可以放心交給它做。
它最大的亮點就是，你可以 用使用excel的手法，用它來開發業務應用。
而且，可視化的 拖拉拽 之後，開發出來的ERP、WMS、OA、進銷存等業務應用，還秉承了MySQL資料庫增刪改查的功能特性。
沒錯，用雲表開發出來的業務應用，是允許二次開發的，而且功能可以隨時增刪改查，輕松滿足大集團精細化的數據控制需求。
不過，大家最關心的應該是數據安全問題吧。
數據存放在雲表內嵌的MySQL資料庫，是安全不丟失的，它提供了多種數據存儲的方式，本地部署，雲端部署，混合部署，任君挑選！
正因如此，像 恆逸石化、許繼電氣、航天科工委、中鐵、中冶、雲南小松 等大型集團，才鼓勵內部員工去學習雲表。
篇幅所限，只說到這里，說太多你也不會看。
免費 的軟獲取方式在下方：
資料庫的用處可大著呢，不僅可以實現數據共享，減少數據冗餘度，還能實現對數據的集中控制，保持數據的一致性和可維護性。選取簡單易用的資料庫，你有什麼好的建議呢，留言讓我們看到噢！
題主強調了簡單易用。所以推薦最簡單三個。
1.Access。
2.Excel。
3.飛書文檔、騰訊文檔、石墨文檔等的表格。
如果要做分析，數據量才比較大，建議Access，還是專業的更好一些。網上教程也很多，比較容易學。而且建議用早一點的版本，比如2003或者2007，Access這些年微軟一直想從office里去掉，奈何用的人還是很多，所以不敢去掉，但是採取了一種比較惡心的方法讓用戶放棄，就是每發布一個新版本，就去掉一些好用的功能，所以說Access是越早的功能越強。
還一個推薦就是Sql Server Express版本，是SQL Server的免費版本，不要錢，基本功能都有，要比sqllite等強大的多
這要結合你個人實際情況來定，有計算機基礎，懂一點資料庫的話那麼市場上的那些軟體都可以用，常用有oracle，sqlserver，mysql等，要上手快還是sqlserver比較快，界面操作也比較直觀；如果一點基礎都沒有，但是又要分析數據的話可以用微軟自帶的一個access，這個上手比較快。決定用哪一種之後還是要買點教材看，簡單的sql查詢要會，熟練之後也能提高工作效率。
個人使用資料庫的話，只存數據不做分析，SQLite就足夠了。
❻ 誰知道資料庫優化設計方案有哪些
本文首先討論了基於第三範式的資料庫表的基本設計，著重論述了建立主鍵和索引的策略和方案，然後從資料庫表的擴展設計和庫表對象的放置等角度概述了資料庫管理系統的優化方案。
關鍵詞： 優化（Optimizing） 第三範式（3NF） 冗餘數據（Rendant Data） 索引（Index） 數據分割（Data Partitioning） 對象放置（Object Placement）
1 引言
資料庫優化的目標無非是避免磁碟I/O瓶頸、減少CPU利用率和減少資源競爭。為了便於讀者閱讀和理解，筆者參閱了Sybase、Informix和Oracle等大型資料庫系統參考資料，基於多年的工程實踐經驗，從基本表設計、擴展設計和資料庫表對象放置等角度進行討論，著重討論了如何避免磁碟I/O瓶頸和減少資源競爭，相信讀者會一目瞭然。
2 基於第三範式的基本表設計
在基於表驅動的信息管理系統（MIS）中，基本表的設計規范是第三範式（3NF）。第三範式的基本特徵是非主鍵屬性只依賴於主鍵屬性。基於第三範式的資料庫表設計具有很多優點：一是消除了冗餘數據，節省了磁碟存儲空間；二是有良好的數據完整性限制，即基於主外鍵的參照完整限制和基於主鍵的實體完整性限制，這使得數據容易維護，也容易移植和更新；三是數據的可逆性好，在做連接（Join）查詢或者合並表時不遺漏、也不重復；四是因消除了冗餘數據（冗餘列），在查詢（Select）時每個數據頁存的數據行就多，這樣就有效地減少了邏輯I/O，每個Cash存的頁面就多，也減少物理I/O；五是對大多數事務(Transaction)而言，運行性能好；六是物理設計(Physical Design)的機動性較大，能滿足日益增長的用戶需求。
在基本表設計中，表的主鍵、外鍵、索引設計佔有非常重要的地位，但系統設計人員往往只注重於滿足用戶要求，而沒有從系統優化的高度來認識和重視它們。實際上，它們與系統的運行性能密切相關。現在從系統資料庫優化角度討論這些基本概念及其重要意義：
（1）主鍵(Primary Key)：主鍵被用於復雜的SQL語句時，頻繁地在數據訪問中被用到。一個表只有一個主鍵。主鍵應該有固定值（不能為Null或預設值，要有相對穩定性），不含代碼信息，易訪問。把常用（眾所周知）的列作為主鍵才有意義。短主鍵最佳（小於25bytes），主鍵的長短影響索引的大小，索引的大小影響索引頁的大小，從而影響磁碟I/O。主鍵分為自然主鍵和人為主鍵。自然主鍵由實體的屬性構成，自然主鍵可以是復合性的，在形成復合主鍵時，主鍵列不能太多，復合主鍵使得Join*作復雜化、也增加了外鍵表的大小。人為主鍵是，在沒有合適的自然屬性鍵、或自然屬性復雜或靈敏度高時，人為形成的。人為主鍵一般是整型值（滿足最小化要求），沒有實際意義，也略微增加了表的大小；但減少了把它作為外鍵的表的大小。
（2）外鍵（Foreign Key）：外鍵的作用是建立關系型資料庫中表之間的關系（參照完整性），主鍵只能從獨立的實體遷移到非獨立的實體，成為後者的一個屬性，被稱為外鍵。
（3）索引(Index)：利用索引優化系統性能是顯而易見的，對所有常用於查詢中的Where子句的列和所有用於排序的列創建索引，可以避免整表掃描或訪問，在不改變表的物理結構的情況下，直接訪問特定的數據列，這樣減少數據存取時間；利用索引可以優化或排除耗時的分類*作；把數據分散到不同的頁面上，就分散了插入的數據；主鍵自動建立了唯一索引，因此唯一索引也能確保數據的唯一性（即實體完整性）；索引碼越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代價：有空間開銷，建立它也要花費時間，在進行Insert、Delete和Update*作時，也有維護代價。索引有兩種：聚族索引和非聚族索引。一個表只能有一個聚族索引，可有多個非聚族索引。使用聚族索引查詢數據要比使用非聚族索引快。在建索引前，應利用資料庫系統函數估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的數據頁按物理有序儲存，佔用空間小。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢或高度重復的列（連續磁碟掃描）；被用於連接Join*作的列；被用於Order by和Group by子句的列。聚族索引不利於插入*作，另外沒有必要用主鍵建聚族索引。
② 非聚族索引（Nonclustered Index）：與聚族索引相比，佔用空間大，而且效率低。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢（在沒有聚族索引時）、主鍵或外鍵列、點（指針類）或小范圍（返回的結果域小於整表數據的20%）查詢；被用於連接Join*作的列、主鍵列（范圍查詢）；被用於Order by和Group by子句的列；需要被覆蓋的列。對只讀表建多個非聚族索引有利。索引也有其弊端，一是創建索引要耗費時間，二是索引要佔有大量磁碟空間，三是增加了維護代價（在修改帶索引的數據列時索引會減緩修改速度）。那麼，在哪種情況下不建索引呢？對於小表（數據小於5頁）、小到中表（不直接訪問單行數據或結果集不用排序）、單值域（返回值密集）、索引列值太長（大於20bitys）、容易變化的列、高度重復的列、Null值列，對沒有被用於Where子語句和Join查詢的列都不能建索引。另外，對主要用於數據錄入的，盡可能少建索引。當然，也要防止建立無效索引，當Where語句中多於5個條件時，維護索引的開銷大於索引的效益，這時，建立臨時表存儲有關數據更有效。
批量導入數據時的注意事項：在實際應用中，大批量的計算（如電信話單計費）用C語言程序做，這種基於主外鍵關系數據計算而得的批量數據（文本文件），可利用系統的自身功能函數（如Sybase的BCP命令）快速批量導入，在導入資料庫表時，可先刪除相應庫表的索引，這有利於加快導入速度，減少導入時間。在導入後再重建索引以便優化查詢。
（4）鎖：鎖是並行處理的重要機制，能保持數據並發的一致性，即按事務進行處理；系統利用鎖，保證數據完整性。因此，我們避免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務的長短；要避免批量數據同時執行，尤其是耗時並用到相同的數據表。鎖的徵用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在等待。若用戶數增加，則Server的性能下降，出現「假死」現象。如何避免死鎖呢？從頁級鎖到行級鎖，減少了鎖徵用；給小表增加無效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響，可選擇合適的聚族索引把數據分配到不同的頁面；創建冗餘表；保持事務簡短；同一批處理應該沒有網路交互。
（5）查詢優化規則：在訪問資料庫表的數據(Access Data)時，要盡可能避免排序（Sort）、連接(Join)和相關子查詢*作。經驗告訴我們，在優化查詢時，必須做到：
① 盡可能少的行；
② 避免排序或為盡可能少的行排序，若要做大量數據排序，最好將相關數據放在臨時表中*作；用簡單的鍵（列）排序，如整型或短字元串排序；
③ 避免表內的相關子查詢；
④ 避免在Where子句中使用復雜的表達式或非起始的子字元串、用長字元串連接；
⑤ 在Where子句中多使用「與」（And）連接，少使用「或」(Or)連接；
⑥ 利用臨時資料庫。在查詢多表、有多個連接、查詢復雜、數據要過濾時，可以建臨時表（索引）以減少I/O。但缺點是增加了空間開銷。
除非每個列都有索引支持，否則在有連接的查詢時分別找出兩個動態索引，放在工作表中重新排序。
3 基本表擴展設計
基於第三範式設計的庫表雖然有其優越性（見本文第一部分），然而在實際應用中有時不利於系統運行性能的優化：如需要部分數據時而要掃描整表，許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程從多表獲取數據時引發大量的連接*作，當數據來源於多表時的連接*作；這都消耗了磁碟I/O和CPU時間。
尤其在遇到下列情形時，我們要對基本表進行擴展設計：許多過程要頻繁訪問一個表、子集數據訪問、重復計算和冗餘數據，有時用戶要求一些過程優先或低的響應時間。
如何避免這些不利因素呢？根據訪問的頻繁程度對相關表進行分割處理、存儲冗餘數據、存儲衍生列、合並相關表處理，這些都是克服這些不利因素和優化系統運行的有效途徑。
3.1 分割表或儲存冗餘數據
分割表分為水平分割表和垂直分割表兩種。分割表增加了維護數據完整性的代價。
水平分割表：一種是當多個過程頻繁訪問數據表的不同行時，水平分割表，並消除新表中的冗餘數據列；若個別過程要訪問整個數據，則要用連接*作，這也無妨分割表；典型案例是電信話單按月分割存放。另一種是當主要過程要重復訪問部分行時，最好將被重復訪問的這些行單獨形成子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但在分割表以後，增加了維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。
垂直分割表（不破壞第三範式），一種是當多個過程頻繁訪問表的不同列時，可將表垂直分成幾個表，減少磁碟I/O（每行的數據列少，每頁存的數據行就多，相應佔用的頁就少），更新時不必考慮鎖，沒有冗餘數據。缺點是要在插入或刪除數據時要考慮數據的完整性，用存儲過程維護。另一種是當主要過程反復訪問部分列時，最好將這部分被頻繁訪問的列數據單獨存為一個子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但這增加了重疊列的維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。垂直分割表可以達到最大化利用Cache的目的。
總之，為主要過程分割表的方法適用於：各個過程需要表的不聯結的子集，各個過程需要表的子集，訪問頻率高的主要過程不需要整表。在主要的、頻繁訪問的主表需要表的子集而其它主要頻繁訪問的過程需要整表時則產生冗餘子集表。
注意，在分割表以後，要考慮重新建立索引。
3.2 存儲衍生數據
對一些要做大量重復性計算的過程而言，若重復計算過程得到的結果相同（源列數據穩定，因此計算結果也不變），或計算牽扯多行數據需額外的磁碟I/O開銷，或計算復雜需要大量的CPU時間，就考慮存儲計算結果（冗餘儲存）。現予以分類說明：
若在一行內重復計算，就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器更新這個新列。
若對表按類進行重復計算，就增加新表（一般而言，存放類和結果兩列就可以了）存儲相關結果。但若參與計算的列被更新時，就必須要用觸發器立即更新、或存儲過程或應用代碼批量更新這個新表。
若對多行進行重復性計算（如排名次），就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器或存儲過程更新這個新列。
總之，存儲冗餘數據有利於加快訪問速度；但違反了第三範式，這會增加維護數據完整性的代價，必須用觸發器立即更新、或存儲過程或應用代碼批量更新，以維護數據的完整性。
3.3 消除昂貴結合
對於頻繁同時訪問多表的一些主要過程，考慮在主表內存儲冗餘數據，即存儲冗餘列或衍生列（它不依賴於主鍵），但破壞了第三範式，也增加了維護難度。在源表的相關列發生變化時，必須要用觸發器或存儲過程更新這個冗餘列。當主要過程總同時訪問兩個表時可以合並表，這樣可以減少磁碟I/O*作，但破壞了第三範式，也增加了維護難度。對父子表和1：1關系表合並方法不同：合並父子表後，產生冗餘表；合並1：1關系表後，在表內產生冗餘數據。
4 資料庫對象的放置策略
資料庫對象的放置策略是均勻地把數據分布在系統的磁碟中，平衡I/O訪問，避免I/O瓶頸。
⑴ 訪問分散到不同的磁碟，即使用戶數據盡可能跨越多個設備，多個I/O運轉，避免I/O競爭，克服訪問瓶頸；分別放置隨機訪問和連續訪問數據。
⑵ 分離系統資料庫I/O和應用資料庫I/O。把系統審計表和臨時庫表放在不忙的磁碟上。
⑶ 把事務日誌放在單獨的磁碟上，減少磁碟I/O開銷，這還有利於在障礙後恢復，提高了系統的安全性。
⑷ 把頻繁訪問的「活性」表放在不同的磁碟上；把頻繁用的表、頻繁做Join*作的表分別放在單獨的磁碟上，甚至把把頻繁訪問的表的欄位放在不同的磁碟上，把訪問分散到不同的磁碟上，避免I/O爭奪；
⑸ 利用段分離頻繁訪問的表及其索引（非聚族的）、分離文本和圖像數據。段的目的是平衡I/O，避免瓶頸，增加吞吐量，實現並行掃描，提高並發度，最大化磁碟的吞吐量。利用邏輯段功能，分別放置「活性」表及其非聚族索引以平衡I/O。當然最好利用系統的默認段。另外，利用段可以使備份和恢復數據更加靈活，使系統授權更加靈活。
❼ 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
❽ mysql資料庫怎麼優化，有幾方面的優化
我列舉幾個我熟悉的，
1，存儲引擎，根據應用選擇合適的引擎
2，索引
----這個就有很多文章了，具體需要你自己去了解
3，sql語句優化，查詢條件的選擇之類
4，mysql自身系統配置，需要針對應用去定製
5，表的選擇，臨時表，或者分區表，也需要針對應用的情況去選擇使用
❾ 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。