mysql文件存儲方式,mysql數據存儲方式

本文目錄一覽：

• 1、mysql最多可以存多少行數據
• 2、win10 MySQL更換儲存路徑
• 3、如何使用mysql存儲所有文件路徑
• 4、MySQL簡單介紹——換個角度認識MySQL
• 5、mysql存儲方式MyISAM 和 InnoDB的區別

mysql最多可以存多少行數據

mysql單表存儲四千萬條數據，操作方法如下：

1、Oracle中大文本數據類型。

2、MySQL資料庫。

3、然後建表。

4、存儲文本時是以字元類型存儲，存儲圖片時是以二進位類型存儲，具體使用的設置參數方法，和獲取數據方法不同。

5、保存照片。

6、獲取照片，就完成了。

win10 MySQL更換儲存路徑

    近幾天在抓Wiki的數據，爬蟲沒控制好導致數據量過大，原數據儲存位置在C盤差點爆了，在網上查詢了更換存儲路徑的方式如下：

1. 在任務管理器-服務里找到MySQL的啟動項-右鍵點屬性，查看配置文件的路徑，我的原有路徑為：C:/ProgramData/MySQL/MySQL Server 8.0/my.ini

2. 在服務中停止MySQL服務，查看my.ini文件中datadir項，進入該目錄下將data文件夾copy至新設定的文件目錄下，我挪到了D:/MySQLData。因為涉及數據最好是複製，等複製完畢再刪除原數據。 同時複製一份my.ini文件至該目錄下，並將my.ini文件中datadir更新至你新設定的路徑D:/MySQLData/data

3. win + R打開運行窗口，regedit打開註冊表，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\路徑下找到MySQL啟動項,名字跟服務中一致,雙擊ImagePath,打開彈窗，把數值數據中my.ini的路徑改為D:\MySQLData\my.ini，確定。

4. 到服務中啟動MySQL，能正常啟動並且能正常連接則遷移完畢。

如何使用mysql存儲所有文件路徑

1、MySQL如果使用MyISAM存儲引擎，資料庫文件類型就包括.frm、.MYD、.MYI，默認存放位置是C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data

2、MySQL如果使用InnoDB存儲引擎，MySQL資料庫文件類型就包括.frm、ibdata1、.ibd，存放位置有兩個，

.frm文件默認存放位置是C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data， ibdata1、.ibd文件默認存放位置是MySQL安裝目錄下的data文件夾

MySQL簡單介紹——換個角度認識MySQL

1、InnoDB存儲引擎

Mysql版本=5.5 默認的存儲引擎，MySQL推薦使用的存儲引擎。支持事務，行級鎖定，外鍵約束。事務安全型存儲引擎。更加註重數據的完整性和安全性。

存儲格式 : 數據，索引集中存儲，存儲於同一個表空間文件中。

InnoDB的行鎖模式及其加鎖方法： InnoDB中有以下兩種類型的行鎖：共享鎖（讀鎖： 允許事務對一條行數據進行讀取）和 互斥鎖（寫鎖： 允許事務對一條行數據進行刪除或更新）， 對於update，insert，delete語句，InnoDB會自動給設計的數據集加互斥鎖，對於普通的select語句，InnoDB不會加任何鎖。

InnoDB行鎖的實現方式： InnoDB行鎖是通過給索引上的索引項加鎖來實現的，如果沒有索引，InnoDB將通過隱藏的聚簇索引來對記錄加鎖。InnoDB這種行鎖實現特點意味著：如果不通過索引條件檢索數據，那麼InnoDB將對表中的所有記錄加鎖，實際效果跟表鎖一樣。

（1）在不通過索引條件查詢時，InnoDB會鎖定表中的所有記錄。

（2）Mysql的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果使用相同的索引鍵，是會出現衝突的。

（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，但都是通過行鎖來對數據加鎖。

優點：

1、支持事務處理、ACID事務特性；

2、實現了SQL標準的四種隔離級別（ 原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（Isolation ）和持續性（Durability ））；

3、支持行級鎖和外鍵約束；

4、可以利用事務日誌進行數據恢復。

5、鎖級別為行鎖，行鎖優點是適用於高並發的頻繁表修改，高並發是性能優於 MyISAM。缺點是系統消耗較大。

6、索引不僅緩存自身，也緩存數據，相比 MyISAM 需要更大的內存。

缺點：

因為它沒有保存表的行數，當使用COUNT統計時會掃描全表。

使用場景：

(1)可靠性要求比較高，或者要求事務；(2)表更新和查詢都相當的頻繁，並且表鎖定的機會比較大的情況。

2、 MyISAM存儲引擎

MySQL= 5.5 MySQL默認的存儲引擎。ISAM：Indexed Sequential Access Method(索引順序存取方法)的縮寫，是一種文件系統。擅長與處理，高速讀與寫。

功能：

（1）支持數據壓縮存儲,但壓縮後的表變成了只讀表，不可寫；如果需要更新數據，則需要先解壓後更新。

（2）支持表級鎖定，不支持高並發；

（3）支持並發插入。寫操作中的插入操作，不會阻塞讀操作（其他操作）；

優點：

1.高性能讀取；

2.因為它保存了表的行數，當使用COUNT統計時不會掃描全表；

缺點：

1、鎖級別為表鎖，表鎖優點是開銷小，加鎖快；缺點是鎖粒度大，發生鎖衝動概率較高，容納並發能力低，這個引擎適合查詢為主的業務。

2、此引擎不支持事務，也不支持外鍵。

3、INSERT和UPDATE操作需要鎖定整個表；

使用場景：

(1)做很多count 的計算；(2)插入不頻繁，查詢非常頻繁；(3)沒有事務。

InnoDB和MyISAM一些細節上的差別：

1、InnoDB不支持FULLTEXT類型的索引，MySQL5.6之後已經支持（實驗性）。

2、InnoDB中不保存表的 具體行數，也就是說，執行select count() from table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count()語句包含 where條件時，兩種表的操作是一樣的。

3、對於AUTO_INCREMENT類型的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引。

4、DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。

5、LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外鍵）的表不適用。

6、另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表。

1．索引概述

利用關鍵字，就是記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分），建立與記錄位置的對應關係，就是索引。索引的關鍵字一定是排序的。索引本質上是表欄位的有序子集，它是提高查詢速度最有效的方法。一個沒有建立任何索引的表，就相當於一本沒有目錄的書，在每次查詢時就會進行全表掃描，這樣會導致查詢效率極低、速度也極慢。如果建立索引，那麼就好比一本添加的目錄，通過目錄的指引，迅速翻閱到指定的章節，提升的查詢性能，節約了查詢資源。

2．索引種類

從索引的定義方式和用途中來看：主鍵索引，唯一索引，普通索引，全文索引。

無論任何類型，都是通過建立關鍵字與位置的對應關係來實現的。索引是通過關鍵字找對應的記錄的地址。

以上類型的差異：對索引關鍵字的要求不同。

關鍵字：記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分）。

普通索引,index：對關鍵字沒有要求。

唯一索引,unique index：要求關鍵字不能重複。同時增加唯一約束。

主鍵索引,primary key：要求關鍵字不能重複，也不能為NULL。同時增加主鍵約束。

全文索引,fulltext key：關鍵字的來源不是所有欄位的數據，而是從欄位中提取的特別關鍵詞。

PS：這裡主鍵索引和唯一索引的區別在於：主鍵索引不能為空值，唯一索引允許空值；主鍵索引在一張表內只能創建一個，唯一索引可以創建多個。主鍵索引肯定是唯一索引，但唯一索引不一定是主鍵索引。

3.索引原則

如果索引不遵循使用原則，則可能導致索引無效。

（1）列獨立

如果需要某個欄位上使用索引，則需要在欄位參與的表達中，保證欄位獨立在一側。否則索引不會用到索引, 例如這條sql就不會用到索引:select * from A where id+1=10;

（2）左原則

Like：匹配模式必須要左邊確定不能以通配符開頭。例如:select * from A where name like ‘%小明%’ ，不會用到索引，而select * from A where name like ‘小明%’ 就可以用到索引（name欄位有建立索引），如果業務上需要用到’%小明%’這種方式,有兩種方法:1.可以考慮全文索引,但mysql的全文索引不支持中文；2.只查詢索引列或主鍵列,例如:select name from A where name like ‘%小明%’ 或 select id from A where name like ‘%小明%’ 或 select id,name from A where name like ‘%小明%’ 這三種情況都會用到name的索引;

複合索引：一個索引關聯多個欄位，僅僅針對左邊欄位有效果，添加複合索引時，第一個欄位很重要，只有包含第一個欄位作為查詢條件的情況才會使用複合索引(必須用到建索引時選擇的第一個欄位作為查詢條件,其他欄位的順序無關),而且查詢條件只能出現and拼接,不能用or,否則則無法使用索引.

（3）OR的使用

必須要保證 OR 兩端的條件都存在可以用的索引，該查詢才可以使用索引。

（4）MySQL智能選擇

即使滿足了上面說原則，MySQL也能棄用索引，例如：select * from A where id 1;這裡棄用索引的主要原因：查詢即使使用索引，會導致出現大量的隨機IO，相對於從數據記錄的第一條遍歷到最後一條的順序IO開銷，還要大。

4.索引的使用場景

（1）索引檢索：檢索數據時使用索引。

（2）索引排序: 如果order by 排序需要的欄位上存在索引，則可能使用到索引。

（3）索引覆蓋: 索引擁有的關鍵字內容，覆蓋了查詢所需要的全部數據，此時，就不需要在數據區獲取數據，僅僅在索引區即可。覆蓋就是直接在索引區獲取內容，而不需要在數據區獲取。例如: select name from A where name like ‘小明%’;

建立索引索引時，不能僅僅考慮where檢索，同時考慮其他的使用場景。（在所有的where欄位上增加索引，就是不合理的）

5.前綴索引

前綴索引是建立索引關鍵字一種方案。通常會使用欄位的整體作為索引關鍵字。有時，即使使用欄位前部分數據，也可以去識別某些記錄。就比如一個班級里，我要找王xx，假如姓王的只有1個人，那麼就可以建一個關鍵字為’王’的前綴索引。語法：Index `index_name` (`index_field`(N))使用index_name前N個字元建立的索引。

6.索引失效

（1） 應盡量避免在 where 子句中使用 != 或 操作符，否則將引擎放棄使用索引而進行全表掃描；

（2） 應盡量避免在 where 子句中使用 or 來連接條件，如果一個欄位有索引，一個欄位沒有索引，將導致引擎放棄使用索引而進行全表掃描；

（3） 應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描；

（4）應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描；如select id from t where num/2 = 100；

（5） 應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描；如：select id from t where substring(name,1,3) = 』abc』 ；

（6）應盡量避免在where子句中對欄位進行類型轉換，這將導致引擎放棄使用索引而進行全表掃描； 如果列類型是字元串，那一定要在條件中將數據使用引號引用起來,如select id from t where id = 1；如果id欄位在表設計中是varchar類型，那麼即使id列上存的是數字，在查詢時也一定要用varchar去匹配，sql應改為select id from t where id = ‘1’；

（7）應盡量避免在where子句中單獨引用複合索引里非第一位置的索引；

join 的兩種演算法：BNL 和 NLJ

NLJ（Nested Loop Join）嵌套循環演算法；以如下 SQL 為例：

select * from t1 join t2 on t1.a=t2.a

SQL 執行時內部流程是這樣的：

1. 先從 t1（假設這裡 t1 被選為驅動表）中取出一行數據 X；

2. 從 X 中取出關聯欄位 a 值，去 t2 中進行查找，滿足條件的行取出；

3. 重複1、2步驟，直到表 t1 最後一行循環結束。

這就是一個嵌套循環的過程，如果在被驅動表上查找數據時可以使用索引，總的對比計算次數等於驅動表滿足 where 條件的行數。假設這裡 t1、t2都是1萬行，則只需要 1萬次計算，這裡用到的是Index Nested-Loops Join（INLJ，基於索引的嵌套循環聯接）。

如果 t1、t2 的 a 欄位都沒有索引，還按照上述的嵌套循環流程查找數據呢？每次在被驅動表上查找數據時都是一次全表掃描，要做1萬次全表掃描，掃描行數等於 1萬+1萬*1萬，這個效率很低，如果錶行數更多，掃描行數動輒幾百億，所以優化器肯定不會使用這樣的演算法，而是選擇 BNL 演算法；

BNLJ（Block Nested Loop Join）塊嵌套循環演算法；

1. 把 t1 表（假設這裡 t1 被選為驅動表）滿足條件的數據全部取出放到線程的 join buffer 中；

2. 每次取 t2 表一行數據，去 joinbuffer 中進行查找，滿足條件的行取出，直到表 t2 最後一行循環結束。

這個演算法下，執行計劃的 Extra 中會出現 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表掃描，總的掃描行數等於 1萬+1萬。但是由於 joinbuffer 維護的是一個無序數組，每次在 joinbuffer 中查找都要遍歷所有行，總的內存計算次數等於1萬*1萬。另外如果 joinbuffer 不夠大放不下驅動表的數據，則要分多次執行上面的流程，會導致被驅動表也做多次全表掃描。

BNLJ相對於NLJ的優點在於，驅動層可以先將部分數據載入進buffer，這種方法的直接影響就是將大大減少內層循環的次數，提高join的效率。

例如：

如果內層循環有100條記錄，外層循環也有100條記錄，這樣的話，每次外層循環先將10條記錄放到buffer中，內層循環的100條記錄每條與這個buffer中的10條記錄進行匹配，只需要匹配內層循環總記錄數次即可結束一次循環（在這裡，即只需要匹配100次即可結束），然後將匹配成功的記錄連接後放入結果集中，接著，外層循環繼續向buffer中放入10條記錄，同理進行匹配，並將成功的記錄連接後放入結果集。後續循環以此類推，直到循環結束，將結果集發給client為止。

可以發現，若用NLJ，則需要100 * 100次才可結束，BNLJ則需要100 / block_size * 100 = 10 * 100次就可結束,大大減少了循環次數。

JOIN 按照功能大致分為如下三類：

JOIN、STRAIGHT_JOIN、INNER JOIN（內連接,或等值連接）：取得兩個表中存在連接匹配關係的記錄。

LEFT JOIN（左連接）：取得左表（table1）完全記錄，即是右表（table2）並無對應匹配記錄。

RIGHT JOIN（右連接）：與 LEFT JOIN 相反，取得右表（table2）完全記錄，即是左表（table1）並無匹配對應記錄。

注意：mysql不支持Full join,不過可以通過UNION 關鍵字來合併 LEFT JOIN 與 RIGHT JOIN來模擬FULL join。

mysql 多表連接查詢方式，因為mysql只支持NLJ演算法,所以如果是小表驅動大表則效率更高；反之則效率下降；因此mysql對內連接或等值連接的方式做了一個優化,會去判斷join表的數據行大小,然後取數據行小的表為驅動表。

INNER JOIN、JOIN、WHERE等值連接和STRAIGHT_JOIN都能表示內連接，那平時如何選擇呢？一般情況下用INNER JOIN、JOIN或者WHERE等值連接，因為MySQL 會按照”小表驅動大表的策略”進行優化。當出現需要排序時，才考慮用STRAIGHT_JOIN指定某張表為驅動表。

兩表JOIN優化

a.當無order by條件時，根據實際情況，使用left/right/inner join即可，根據explain優化 ；

b.當有order by條件時，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解釋語句；

1）如果第一行的驅動表為a，則效率會非常高，無需優化；

2）否則，因為只能對驅動表欄位直接排序的緣故，會出現using temporary，所以此時需要使用STRAIGHT_JOIN明確a為驅動表，來達到使用a.col上index的優化目的；或者使用left join且Where條件中不含b的過濾條件，此時的結果集為a的全集，而STRAIGHT_JOIN為inner join且使用a作為驅動表。註：使用STRAIGHT_JOIN雖然不會using temporary，但也不是一定就能提高效率，如果a表數據遠遠超過b表，那麼有可能使用STRAIGHT_JOIN時比原來的sql效率更低，所以怎麼使用STRAIGHT_JOIN，還是要視情況而定。

在使用left join（或right join）時，應該清楚的知道以下幾點：

(1). on與 where的執行順序

ON 條件（「A LEFT JOIN B ON 條件表達式」中的ON）用來決定如何從 B 表中檢索數據行。如果 B 表中沒有任何一行數據匹配 ON 的條件,將會額外生成一行所有列為 NULL 的數據,在匹配階段 WHERE 子句的條件都不會被使用。僅在匹配階段完成以後，WHERE 子句條件才會被使用。它將從匹配階段產生的數據中檢索過濾。

所以我們要注意：在使用Left (right) join的時候，一定要在先給出儘可能多的匹配滿足條件，減少Where的執行。

(2).注意ON 子句和 WHERE 子句的不同

即使右表的數據不滿足ON後面的條件,也會在結果集拼接一條為NULL的數據行,但WHERE後面的條件不一樣,右表不滿足WHERE的條件,左表關聯的數據也會被過濾掉。

(3).盡量避免子查詢，而用join

往往性能這玩意兒，更多時候體現在數據量比較大的時候，此時，我們應該避免複雜的子查詢。

（1）in 和 not in 要慎用，如：select id from t where num in(1,2,3)對於連續的數值，能用 between 就不要用 in：select id from t where num between 1 and 3很多時候用 exists 代替 in 是一個好的選擇：select num from a where num in(select num from b)用下面的語句替換：select num from a where exists(select 1 from b where num=a.num)

（2）Update 語句，如果只更改1、2個欄位，不要Update全部欄位，否則頻繁調用會引起明顯的性能消耗，同時帶來大量日誌。

（3）join語句,MySQL裡面的join是用小表去驅動大表,而由於MySQL join實現的原理就是做循環，比如left join就是對左邊的數據進行循環去驅動右邊的表,左邊有m條記錄匹配,右邊有n條記錄那麼就是做m次循環,每次掃描n行數據,總掃面行數是m*n行數據。左邊返回的結果集的大小就決定了循環的次數,故單純的用小表去驅動大表不一定的正確的,小表的結果集可能也大於大表的結果集,所以寫join的時候儘可能的先估計兩張表的可能結果集,用小結果集去驅動大結果集.值得注意的是在使用left/right join的時候,從表的條件應寫在on之後,主表應寫在where之後.否則MySQL會當作普通的連表查詢；

（4）select count(*) from table；這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的；

（5）select * from t 這種語句要盡量避免，使用具體的欄位代替*，更有實際意義，需要什麼欄位就返回什麼欄位；

（6）數據量大的情況下，limit要慎用，因為使用limit m，n方式分頁時，mysql每次都是查詢前m+n條，然後捨棄前m條，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20這鐘，查詢效率就會非常低，當分頁的頁數大於一定的數量之後，就可以換種方式來分頁：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id;

mysql存儲方式MyISAM 和 InnoDB的區別

MYISAM 表是典型的數據與索引分離存儲，主鍵和二級索引沒有本質區別。比如在 MYISAM 表裡主鍵、唯一索引是一樣的，沒有本質區別。

INNODB 表本身是索引組織表，也就是說索引就是數據。下圖表T1的數據行以聚簇索引的方式展示，非葉子節點保存了主鍵的值，葉子節點保存了主鍵的值以及對應的數據行，並且每個頁有分別指向前後兩頁的指針。

INNODB 表不同於 MYISAM，INNODB 表有自己的數據頁管理，默認 16KB。MYISAM 表數據的管理依賴文件系統，比如文件系統一般默認 4KB，MYISAM的塊大小也是 4KB，MYISAM 表的沒有自己的一套崩潰恢復機制，全部依賴於文件系統。

INNODB 表這樣設計的優點有兩個：

1. 數據按照主鍵順序存儲。主鍵的順序也就是記錄行的物理順序，相比指向數據行指針的存放方式，避免了再次排序。我們知道，排序消耗最大。

2. 兩個葉子節點分別含有指向前後兩個節點的指針，這樣在插入新行或者進行頁分裂時，只需要移動對應的指針即可。

INNODB 二級索引的非葉子節點保存索引的欄位值，上圖索引為表 t1 的欄位 age。葉子節點含有索引欄位值和對應的主鍵值。

這樣做的優點是當出現數據行移動或者數據頁分裂時，避免二級索引不必要的維護工作。當數據需要更新的時候，二級索引不需要重建，只需要修改聚簇索引即可。

但是也有缺點：

1. 二級索引由於同時保存了主鍵值，體積會變大。特別是主鍵設計不合理的時候，比如用 UUID 做主鍵。

2. 對二級索引的檢索需要檢索兩次索引樹。第一次通過檢索二級索引葉子節點，找到過濾行對應的主鍵值；第二次通過這個主鍵的值去聚簇索引中查找對應的行。