本文目錄一覽:
如何理解並正確使用MySql索引
MySQL索引類型包括:
(1)普通索引
這是最基本的索引,它沒有任何限制。它有以下幾種創建方式:
◆創建索引
CREATE INDEX indexName ON mytable(username(length)); 如果是CHAR,VARCHAR類型,length可以小於字段實際長度;如果是BLOB和TEXT類型,必須指定 length,下同。
◆修改表結構
ALTER mytable ADD INDEX [indexName] ON (username(length))
◆創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); 刪除索引的語法:
DROP INDEX [indexName] ON mytable;
(2)唯一索引
與前面的普通索引類似,不同的就是:索引列的值必須唯一,但允許有空值。如果是組合索引,則列值的組合必須唯一。它有以下幾種創建方式:
◆創建索引
CREATE UNIQUE INDEX indexName ON mytable(username(length))
◆修改表結構
ALTER mytable ADD UNIQUE [indexName] ON (username(length))
mysql數據庫優化講解之索引:什麼是索引
定義:存在於關係型數據庫中,是一種與表有關的數據庫對象
以存儲方式分類可以分為
B*樹
位圖
優點:提高檢索速度
使用原則(何時需要創建索引):
哪些表需要創建索引:
某表常被訪問或某表數據量較大
通常以哪些字段作為索引:
某字段常被作為查詢條件
MySQL數據庫的四類索引?
index —- 普通索引,數據可以重複,沒有任何限制。
unique —- 唯一索引,要求索引列的值必須唯一,但允許有空值;如果是組合索引,那麼列值的組合必須唯一。
primary key —- 主鍵索引,是一種特殊的唯一索引,一個表只能有一個主鍵,不允許有空值,一般是在創建表的同時創建主鍵索引。
組合索引 —- 在多個字段上創建的索引,只有在查詢條件中使用了創建索引時的第一個字段,索引才會被使用。
fulltext —- 全文索引,是對於大表的文本域:char,varchar,text列才能創建全文索引,主要用於查找文本中的關鍵字,並不是直接與索引中的值進行比較。fulltext更像是一個搜索引擎,配合match against操作使用,而不是一般的where語句加like。
注:全文索引目前只有MyISAM存儲引擎支持全文索引,InnoDB引擎5.6以下版本還不支持全文索引
所有存儲引擎對每個表至少支持16個索引,總索引長度至少為256字節,索引有兩種存儲類型,包括B型樹索引和哈希索引。
索引可以提高查詢的速度,但是創建和維護索引需要耗費時間,同時也會影響插入的速度,如果需要插入大量的數據時,最好是先刪除索引,插入數據後再建立索引。
超詳細MySQL數據庫優化
數據庫優化一方面是找出系統的瓶頸,提高MySQL數據庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要儘可能的節約系統資源,以便讓系統提供更大的負荷.
1. 優化一覽圖
2. 優化
筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作數據庫即可,而硬優化則是操作服務器硬件及參數設置.
2.1 軟優化
2.1.1 查詢語句優化
1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.
2.例:
顯示:
其中會顯示索引和查詢數據讀取數據條數等信息.
2.1.2 優化子查詢
在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.
2.1.3 使用索引
索引是提高數據庫查詢速度最重要的方法之一,關於索引可以參高筆者MySQL數據庫索引一文,介紹比較詳細,此處記錄使用索引的三大注意事項:
2.1.4 分解表
對於字段較多的表,如果某些字段使用頻率較低,此時應當,將其分離出來從而形成新的表,
2.1.5 中間表
對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.
2.1.6 增加冗餘字段
類似於創建中間表,增加冗餘也是為了減少連接查詢.
2.1.7 分析表,,檢查表,優化表
分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.
1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;
2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]
option 只對MyISAM有效,共五個參數值:
3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.
2.2 硬優化
2.2.1 硬件三件套
1.配置多核心和頻率高的cpu,多核心可以執行多個線程.
2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁盤I/O時間,從而提高響應速度.
3.配置高速磁盤或合理分布磁盤:高速磁盤提高I/O,分布磁盤能提高並行操作的能力.
2.2.2 優化數據庫參數
優化數據庫參數可以提高資源利用率,從而提高MySQL服務器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.
2.2.3 分庫分表
因為數據庫壓力過大,首先一個問題就是高峰期系統性能可能會降低,因為數據庫負載過高對性能會有影響。另外一個,壓力過大把你的數據庫給搞掛了怎麼辦?所以此時你必須得對系統做分庫分表 + 讀寫分離,也就是把一個庫拆分為多個庫,部署在多個數據庫服務上,這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫,由從庫來承載讀請求。
2.2.4 緩存集群
如果用戶量越來越大,此時你可以不停的加機器,比如說系統層面不停加機器,就可以承載更高的並發請求。然後數據庫層面如果寫入並發越來越高,就擴容加數據庫服務器,通過分庫分表是可以支持擴容機器的,如果數據庫層面的讀並發越來越高,就擴容加更多的從庫。但是這裡有一個很大的問題:數據庫其實本身不是用來承載高並發請求的,所以通常來說,數據庫單機每秒承載的並發就在幾千的數量級,而且數據庫使用的機器都是比較高配置,比較昂貴的機器,成本很高。如果你就是簡單的不停的加機器,其實是不對的。所以在高並發架構里通常都有緩存這個環節,緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬,甚至每秒數十萬,對高並發的承載能力比數據庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性,對那種寫少讀多的請求,引入緩存集群。具體來說,就是在寫數據庫的時候同時寫一份數據到緩存集群里,然後用緩存集群來承載大部分的讀請求。這樣的話,通過緩存集群,就可以用更少的機器資源承載更高的並發。
一個完整而複雜的高並發系統架構中,一定會包含:各種複雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是數據庫優化的思想差不多就這些了.
MYSQL的索引主要作用是什麼!
索引可以加快數據檢索操作,但會使數據修改操作變慢。每修改數據記錄,索引就必須刷新一次。為了在某種程度上彌補這一缺陷,許多SQL命令都有一個DELAY_KEY_WRITE項。
這個選項的作用是暫時制止MySQL在該命令每插入一條新記錄和每修改一條現有之後立刻對索引進行刷新,對索引的刷新將等到全部記錄插入/修改完畢之後再進行。在需要把許多新記錄插入某個數據表的場合,DELAY_KEY_WRITE選項的作用將非常明顯。
另外,索引還會在硬盤上佔用相當大的空間。因此應該只為最經常查詢和最經常排序的數據列建立索引。如果某個數據列包含許多重複的內容,為它建立索引就沒有太大的實際效果。
擴展資料
從理論上講,完全可以為數據表裡的每個字段分別建一個索引,但MySQL把同一個數據表裡的索引總數限制為16個。
與InnoDB數據表相比,在InnoDB數據表上,索引對Inn數據表的重要性要大得多。在 InnoDB 數據表上,索引不僅會在搜索數據記錄時發揮作用,還是數據行級鎖定機制的基礎。
在為MySQL分配足夠的內存之前,請考慮不同領域對MySQL的內存需求。要考慮的關鍵領域是:並發連接——對於大量並發連接,排序和臨時表將需要大量內存。在撰寫本文時,對於處理3000+並發連接的數據庫,16GB到32GB的RAM是足夠的。
參考資料來源:百度百科-MySQL數據庫
參考資料來源:百度百科-mySQL
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/231392.html