网站3.4升级到3.5 文件大3倍了

tanshancai

网站3.4的时候才4G升级到3.5后变成了12G 是啥情况

我知道答案 回答被采纳将会获得1 贡献 已有10人回答

mingkong

是指的哪里的文件体积？
附件变多了还是数据库体积变大？

卡卡北

对，就是这样，x3.4由GBK转UTF8数据库涨30%，由x3.4 UTF8转x3.5数据库涨差不多三倍。

tanshancai

数据库也大了许多 最主要是文件大了很大倍   开始3.4的时候我备份了是4个G  升级完后 我在备份提示12个G

tanshancai

卡卡北 发表于 2023-7-9 16:11
对，就是这样，x3.4由GBK转UTF8数据库涨30%，由x3.4 UTF8转x3.5数据库涨差不多三倍。 ...

我的是3.4的utf-8

湖中沉

数据库变大是因为数据库引擎变更为innodb，这个引擎数据库体积就是会变大的，再加上你GBK变UTF8也会变大大概30%，所以原先数据库如果是4G，那么转为UTF8后大约5.5G，再转为innodb引擎，可能就会到达6-8G，属于正常现象。innodb优点很多，但体积就是比以前旧的引擎要大。

关于文件体积变大，更多的可能是你把一些旧的备份文件一起保留并打包进去了

卡卡北

湖中沉 发表于 2023-7-9 16:18
数据库变大是因为数据库引擎变更为innodb，这个引擎数据库体积就是会变大的，再加上你GBK变UTF8也会变大大 ...

我退回去了，gbk转uft8数据库体积涨了30%能接受，转换innodb体积又在这个基础涨了差不多三倍，接受不了。。。

湖中沉

卡卡北 发表于 2023-7-9 16:30
我退回去了，gbk转uft8数据库体积涨了30%能接受，转换innodb体积又在这个基础涨了差不多三倍，接受不了。 ...

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

当前云数据库已经非常普遍，大多数云数据库都不支持MyISAM引擎，所以InnoDB是面对未来的必选





事务差异

InnoDB是MySQL的事务型存储引擎，支持ACID特性（原子性、一致性、隔离性和持久性），可以保证数据的完整性和一致性。而MyISAM不支持事务，这意味着在高并发的环境下，使用InnoDB更加可靠。

外键差异

InnoDB是唯一支持外键的存储引擎，可以通过外键约束来保持数据的一致性。而MyISAM不支持外键约束，因此在需要使用外键的情况下，选择InnoDB是更好的选择。

索引差异

InnoDB和MyISAM对索引的处理方式也有所不同。InnoDB使用聚簇索引（clustered index），它的叶子节点存储了实际的数据行，这样可以加快根据索引进行数据检索的速度。而MyISAM使用非聚簇索引（non-clustered index），叶子节点存储的是指向实际数据行的指针。因此，在需要频繁进行数据检索的场景中，InnoDB的性能更好。

行锁差异

在并发访问的情况下，InnoDB使用行级锁（row-level locking），可以提供更好的并发性能。而MyISAM只支持表级锁（table-level locking），这就意味着当一个线程对表进行写操作时，其他线程无法对该表进行任何读写操作。

表锁差异

MyISAM的表级锁对于整个表进行锁定，因此在高并发的情况下可能导致较多的锁冲突，降低了并发性能。而InnoDB的行级锁可以最大程度地减少锁冲突，提高了并发性能。

存储文件差异

InnoDB的数据和索引是存储在一个共享的表空间文件中的，而MyISAM则将数据和索引分别存储在不同的文件中。这也是为什么InnoDB在存储空间利用率上相对较低的原因之一。

具体行数差异

在大多数情况下，InnoDB的表通常需要占用更多的存储空间，因为它包含了额外的数据结构来支持事务和行级锁等功能。而MyISAM则相对更加轻量级。

湖中沉

卡卡北 发表于 2023-7-9 16:30
我退回去了，gbk转uft8数据库体积涨了30%能接受，转换innodb体积又在这个基础涨了差不多三倍，接受不了。 ...

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

当前云数据库已经非常普遍，大多数云数据库都不支持MyISAM，所以转为InnoDB是面对未来的必选项。



事务差异

InnoDB是MySQL的事务型存储引擎，支持ACID特性（原子性、一致性、隔离性和持久性），可以保证数据的完整性和一致性。而MyISAM不支持事务，这意味着在高并发的环境下，使用InnoDB更加可靠。

外键差异

InnoDB是唯一支持外键的存储引擎，可以通过外键约束来保持数据的一致性。而MyISAM不支持外键约束，因此在需要使用外键的情况下，选择InnoDB是更好的选择。

索引差异

InnoDB和MyISAM对索引的处理方式也有所不同。InnoDB使用聚簇索引（clustered index），它的叶子节点存储了实际的数据行，这样可以加快根据索引进行数据检索的速度。而MyISAM使用非聚簇索引（non-clustered index），叶子节点存储的是指向实际数据行的指针。因此，在需要频繁进行数据检索的场景中，InnoDB的性能更好。

行锁差异

在并发访问的情况下，InnoDB使用行级锁（row-level locking），可以提供更好的并发性能。而MyISAM只支持表级锁（table-level locking），这就意味着当一个线程对表进行写操作时，其他线程无法对该表进行任何读写操作。

表锁差异

MyISAM的表级锁对于整个表进行锁定，因此在高并发的情况下可能导致较多的锁冲突，降低了并发性能。而InnoDB的行级锁可以最大程度地减少锁冲突，提高了并发性能。

存储文件差异

InnoDB的数据和索引是存储在一个共享的表空间文件中的，而MyISAM则将数据和索引分别存储在不同的文件中。这也是为什么InnoDB在存储空间利用率上相对较低的原因之一。

具体行数差异

在大多数情况下，InnoDB的表通常需要占用更多的存储空间，因为它包含了额外的数据结构来支持事务和行级锁等功能。而MyISAM则相对更加轻量级。

tanshancai

其实我想表达的是 不是数据库文件变大了  是那个程序文件翻了三倍 我是utf-8 升级的