关于x3.5用myisam引擎安装问题
2023-07-24 19:28 来自 迪巴拉 发布@ Discuz!问题求助
看到x3.5支持myisam引擎
43603
就安装了一下，安装环境如下：
43604
将upload\config\config_global_default.php中
$_config = 'innodb';改为：
$_config = 'myisam';
只是改这里安装会进行不下去，会有以下提示：
43605
需要以下两种方法才能继续安装
第一种，数据库跳过innodb
43606
第二种，无法改数据库参数的话，不跳过innodb，改安装文件
upload\install\data\install.sql 和 upload\uc_server\install\uc.sql 中
ENGINE=InnoDB;改为：
ENGINE=MyISAM;两种方法都可以安装成功
但是安装成功后，只能发帖
43607
发不了回复：
43608
请问如何处理？
我知道答案 回答被采纳将会获得1 贡献 已有4人回答
43603
就安装了一下，安装环境如下：
43604
将upload\config\config_global_default.php中
$_config = 'innodb';改为：
$_config = 'myisam';
只是改这里安装会进行不下去，会有以下提示：
43605
需要以下两种方法才能继续安装
第一种，数据库跳过innodb
43606
第二种，无法改数据库参数的话，不跳过innodb，改安装文件
upload\install\data\install.sql 和 upload\uc_server\install\uc.sql 中
ENGINE=InnoDB;改为：
ENGINE=MyISAM;两种方法都可以安装成功
但是安装成功后，只能发帖
43607
发不了回复：
43608
请问如何处理？
我知道答案 回答被采纳将会获得1 贡献 已有4人回答
discuzx3.4，myisam，数据库内的forum_hotreply_number表老是报错
2023-03-14 12:15 来自 镖师 发布@ Discuz!问题求助
后台工具---》系统错误内频繁出现此类错误：
(1062) Duplicate entry '18318062' for key 'PRIMARY'
INSERT INTO forum_hotreply_number SET `pid`='18318062' , `tid`='8279589' , `support`='0' , `against`='0' , `total`='0'
PHP:
forum.php#require(%s):0067
source/module/forum/forum_misc.php#discuz_table->discuz_table->insert():1795
source/class/discuz/discuz_table.php#discuz_database::discuz_database::insert():0081
source/class/discuz/discuz_database.php#discuz_database::discuz_database::query():0060
source/clas
(1062) Duplicate entry '18318062' for key 'PRIMARY'
INSERT INTO forum_hotreply_number SET `pid`='18318062' , `tid`='8279589' , `support`='0' , `against`='0' , `total`='0'
PHP:
forum.php#require(%s):0067
source/module/forum/forum_misc.php#discuz_table->discuz_table->insert():1795
source/class/discuz/discuz_table.php#discuz_database::discuz_database::insert():0081
source/class/discuz/discuz_database.php#discuz_database::discuz_database::query():0060
source/clas
discuz x3.4升级到discuz x3.5数据库如果过GB会存在备份数据库增长几倍几G的情况的根本原因
2023-07-12 16:17 来自 惧愁人 发布@ Discuz! X3.5专区
有很多站长从discuz x3.4升级到discuz x3.5后发现，原先仅是1.几G的网站备份数据，升级之后增长了将近3倍大小，造成了备份成本、空间成本、容量成本增长不少，这主要是x3.5的数据库引擎更改为了innodb造成。
一般innodb比MyISAM大30%左右，如果你是GBK升级的，那么就是 原大小 x 130% x 130%
当前云数据库已经非常普遍，大多数云数据库都不支持MyISAM引擎，所以InnoDB是面对未来的必选，这也是X3.5的升级特性之一。
升级到X3.5数据库差异性对比：
事务差异InnoDB是MySQL的事务型存储引擎，支持ACID特性（原子性、一致性、隔离性和持久性），可以保证数据的完整性和一致性。而MyISAM不支持事务，这意味着在高并发的环境下，使用InnoDB更加可靠。
外键差异InnoDB是唯一支持外键的存储引擎，可以通过外键约束来保持数据的一致性。而MyISAM不支持外键约束，因此在需要使用外键的情况下，选择InnoDB是更好的选择。
索引差异InnoDB和MyISAM对索引的处理方式也有所不同。InnoDB使用聚
一般innodb比MyISAM大30%左右，如果你是GBK升级的，那么就是 原大小 x 130% x 130%
当前云数据库已经非常普遍，大多数云数据库都不支持MyISAM引擎，所以InnoDB是面对未来的必选，这也是X3.5的升级特性之一。
升级到X3.5数据库差异性对比：
事务差异InnoDB是MySQL的事务型存储引擎，支持ACID特性（原子性、一致性、隔离性和持久性），可以保证数据的完整性和一致性。而MyISAM不支持事务，这意味着在高并发的环境下，使用InnoDB更加可靠。
外键差异InnoDB是唯一支持外键的存储引擎，可以通过外键约束来保持数据的一致性。而MyISAM不支持外键约束，因此在需要使用外键的情况下，选择InnoDB是更好的选择。
索引差异InnoDB和MyISAM对索引的处理方式也有所不同。InnoDB使用聚
3.4升级3.5成功后
2023-03-10 07:27 来自 哥斯拉 发布@ Discuz!问题求助
数据表也变成了 InnoDB utf8mb4_unicode_ci
是从08年用DZ一步一步升级上来的。
UC的数据库还是 cdb_uc 的表前缀
但是我发现其中还有一些表还是
cdb_uc_pms MyISAM utf8_general_ci
pre_forum_postposition MyISAM utf8_general_ci
32203
请问这些表能删除吗？
1 贡献+1 金币最佳答案
这几个是已经被废弃的表，甚至可以直接删除
32204湖中沉发表于昨天 22:52
详细答案 >
是从08年用DZ一步一步升级上来的。
UC的数据库还是 cdb_uc 的表前缀
但是我发现其中还有一些表还是
cdb_uc_pms MyISAM utf8_general_ci
pre_forum_postposition MyISAM utf8_general_ci
32203
请问这些表能删除吗？
1 贡献+1 金币最佳答案
这几个是已经被废弃的表，甚至可以直接删除
32204湖中沉发表于昨天 22:52
详细答案 >
UCenter1.7.0升级出错
2023-02-21 07:44 来自 浅生 发布@ Discuz! X3.5专区
500 - 内部服务器错误。 uc_server/install/update_ucenter_adult.php?step=scheme&myisam=0&id=3
X3.5将对取消数据库UTF8编码的支持，转为UTF8-mb4编码
2020-07-08 10:16 来自 admin 发布@ Discuz! X3.5专区
X3.5版本，支持InnoDB与MyISAM两种数据库引擎，在两种引擎下数据库都不再支持utf8编码，转而支持utf8mb4编码。
无论是InnoDB还是MyISAM，所有的表都使用utf8mb4编码与utf8mb4_unicode_ci，该编码的支持，将直接导致X3.5支持emoj表情。
MySQL在5.5.3之后增加了这个utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。好在utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。当然，为了节省空间，一般情况下使用utf8也就够了。既然utf8能够存下大部分中文汉字,那为什么还要使用utf8mb4呢? 原来mysql支持的 utf8 编码最大字符长度为 3 字节，如果遇到 4 字节的宽字符就会插入异常了。三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xffff，也就是 Unicode 中的基本多文种平面(BMP)。也就是说，任何不在基本多文本平面的 Unicode字符，都无法使用 Mysql 的 utf8 字符
无论是InnoDB还是MyISAM，所有的表都使用utf8mb4编码与utf8mb4_unicode_ci，该编码的支持，将直接导致X3.5支持emoj表情。
MySQL在5.5.3之后增加了这个utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。好在utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。当然，为了节省空间，一般情况下使用utf8也就够了。既然utf8能够存下大部分中文汉字,那为什么还要使用utf8mb4呢? 原来mysql支持的 utf8 编码最大字符长度为 3 字节，如果遇到 4 字节的宽字符就会插入异常了。三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xffff，也就是 Unicode 中的基本多文种平面(BMP)。也就是说，任何不在基本多文本平面的 Unicode字符，都无法使用 Mysql 的 utf8 字符
