網(wǎng)站3.4升級到3.5 文件大3倍了

tanshancai

網(wǎng)站3.4的時候才4G升級到3.5后變成了12G 是啥情況

我知道答案 回答被采納將會獲得1 貢獻 已有10人回答

mingkong

是指的哪里的文件體積？
附件變多了還是數(shù)據(jù)庫體積變大？

卡卡北

對，就是這樣，x3.4由GBK轉(zhuǎn)UTF8數(shù)據(jù)庫漲30%，由x3.4 UTF8轉(zhuǎn)x3.5數(shù)據(jù)庫漲差不多三倍。

tanshancai

數(shù)據(jù)庫也大了許多 最主要是文件大了很大倍   開始3.4的時候我備份了是4個G  升級完后 我在備份提示12個G

tanshancai

卡卡北 發(fā)表于 2023-7-9 16:11
對，就是這樣，x3.4由GBK轉(zhuǎn)UTF8數(shù)據(jù)庫漲30%，由x3.4 UTF8轉(zhuǎn)x3.5數(shù)據(jù)庫漲差不多三倍。 ...

我的是3.4的utf-8

湖中沉

數(shù)據(jù)庫變大是因為數(shù)據(jù)庫引擎變更為innodb，這個引擎數(shù)據(jù)庫體積就是會變大的，再加上你GBK變UTF8也會變大大概30%，所以原先數(shù)據(jù)庫如果是4G，那么轉(zhuǎn)為UTF8后大約5.5G，再轉(zhuǎn)為innodb引擎，可能就會到達6-8G，屬于正常現(xiàn)象。innodb優(yōu)點很多，但體積就是比以前舊的引擎要大。

關于文件體積變大，更多的可能是你把一些舊的備份文件一起保留并打包進去了

卡卡北

湖中沉 發(fā)表于 2023-7-9 16:18
數(shù)據(jù)庫變大是因為數(shù)據(jù)庫引擎變更為innodb，這個引擎數(shù)據(jù)庫體積就是會變大的，再加上你GBK變UTF8也會變大大 ...

我退回去了，gbk轉(zhuǎn)uft8數(shù)據(jù)庫體積漲了30%能接受，轉(zhuǎn)換innodb體積又在這個基礎漲了差不多三倍，接受不了。。。

湖中沉

卡卡北 發(fā)表于 2023-7-9 16:30
我退回去了，gbk轉(zhuǎn)uft8數(shù)據(jù)庫體積漲了30%能接受，轉(zhuǎn)換innodb體積又在這個基礎漲了差不多三倍，接受不了。 ...

三倍是不可能的，一般innodb比MyISAM大30%左右，如果你是GBK升級的，那么就是 原大小 x 130% x 130%

當前云數(shù)據(jù)庫已經(jīng)非常普遍，大多數(shù)云數(shù)據(jù)庫都不支持MyISAM引擎，所以InnoDB是面對未來的必選





事務差異

InnoDB是MySQL的事務型存儲引擎，支持ACID特性（原子性、一致性、隔離性和持久性），可以保證數(shù)據(jù)的完整性和一致性。而MyISAM不支持事務，這意味著在高并發(fā)的環(huán)境下，使用InnoDB更加可靠。

外鍵差異

InnoDB是唯一支持外鍵的存儲引擎，可以通過外鍵約束來保持數(shù)據(jù)的一致性。而MyISAM不支持外鍵約束，因此在需要使用外鍵的情況下，選擇InnoDB是更好的選擇。

索引差異

InnoDB和MyISAM對索引的處理方式也有所不同。InnoDB使用聚簇索引（clustered index），它的葉子節(jié)點存儲了實際的數(shù)據(jù)行，這樣可以加快根據(jù)索引進行數(shù)據(jù)檢索的速度。而MyISAM使用非聚簇索引（non-clustered index），葉子節(jié)點存儲的是指向?qū)嶋H數(shù)據(jù)行的指針。因此，在需要頻繁進行數(shù)據(jù)檢索的場景中，InnoDB的性能更好。

行鎖差異

在并發(fā)訪問的情況下，InnoDB使用行級鎖（row-level locking），可以提供更好的并發(fā)性能。而MyISAM只支持表級鎖（table-level locking），這就意味著當一個線程對表進行寫操作時，其他線程無法對該表進行任何讀寫操作。

表鎖差異

MyISAM的表級鎖對于整個表進行鎖定，因此在高并發(fā)的情況下可能導致較多的鎖沖突，降低了并發(fā)性能。而InnoDB的行級鎖可以最大程度地減少鎖沖突，提高了并發(fā)性能。

存儲文件差異

InnoDB的數(shù)據(jù)和索引是存儲在一個共享的表空間文件中的，而MyISAM則將數(shù)據(jù)和索引分別存儲在不同的文件中。這也是為什么InnoDB在存儲空間利用率上相對較低的原因之一。

具體行數(shù)差異

在大多數(shù)情況下，InnoDB的表通常需要占用更多的存儲空間，因為它包含了額外的數(shù)據(jù)結(jié)構(gòu)來支持事務和行級鎖等功能。而MyISAM則相對更加輕量級。

湖中沉

卡卡北 發(fā)表于 2023-7-9 16:30
我退回去了，gbk轉(zhuǎn)uft8數(shù)據(jù)庫體積漲了30%能接受，轉(zhuǎn)換innodb體積又在這個基礎漲了差不多三倍，接受不了。 ...

三倍是不可能的，一般innodb比MyISAM大30%左右，如果你是GBK升級的，那么就是 原大小 x 130% x 130%

當前云數(shù)據(jù)庫已經(jīng)非常普遍，大多數(shù)云數(shù)據(jù)庫都不支持MyISAM，所以轉(zhuǎn)為InnoDB是面對未來的必選項。



事務差異

InnoDB是MySQL的事務型存儲引擎，支持ACID特性（原子性、一致性、隔離性和持久性），可以保證數(shù)據(jù)的完整性和一致性。而MyISAM不支持事務，這意味著在高并發(fā)的環(huán)境下，使用InnoDB更加可靠。

外鍵差異

InnoDB是唯一支持外鍵的存儲引擎，可以通過外鍵約束來保持數(shù)據(jù)的一致性。而MyISAM不支持外鍵約束，因此在需要使用外鍵的情況下，選擇InnoDB是更好的選擇。

索引差異

InnoDB和MyISAM對索引的處理方式也有所不同。InnoDB使用聚簇索引（clustered index），它的葉子節(jié)點存儲了實際的數(shù)據(jù)行，這樣可以加快根據(jù)索引進行數(shù)據(jù)檢索的速度。而MyISAM使用非聚簇索引（non-clustered index），葉子節(jié)點存儲的是指向?qū)嶋H數(shù)據(jù)行的指針。因此，在需要頻繁進行數(shù)據(jù)檢索的場景中，InnoDB的性能更好。

行鎖差異

在并發(fā)訪問的情況下，InnoDB使用行級鎖（row-level locking），可以提供更好的并發(fā)性能。而MyISAM只支持表級鎖（table-level locking），這就意味著當一個線程對表進行寫操作時，其他線程無法對該表進行任何讀寫操作。

表鎖差異

MyISAM的表級鎖對于整個表進行鎖定，因此在高并發(fā)的情況下可能導致較多的鎖沖突，降低了并發(fā)性能。而InnoDB的行級鎖可以最大程度地減少鎖沖突，提高了并發(fā)性能。

存儲文件差異

InnoDB的數(shù)據(jù)和索引是存儲在一個共享的表空間文件中的，而MyISAM則將數(shù)據(jù)和索引分別存儲在不同的文件中。這也是為什么InnoDB在存儲空間利用率上相對較低的原因之一。

具體行數(shù)差異

在大多數(shù)情況下，InnoDB的表通常需要占用更多的存儲空間，因為它包含了額外的數(shù)據(jù)結(jié)構(gòu)來支持事務和行級鎖等功能。而MyISAM則相對更加輕量級。

tanshancai

其實我想表達的是 不是數(shù)據(jù)庫文件變大了  是那個程序文件翻了三倍 我是utf-8 升級的