ALTER TABLE `user`
ADD COLUMN `cdkey` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT 'CD-Key',
ADD COLUMN `erp_userid` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT 'ERP用户ID',
ADD UNIQUE INDEX `uniq_cdkey_erp_userid`(`cdkey`, `erp_userid`) USING BTREE;
当前表：
CREATE TABLE `user` (
`id` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'id',
`username` char(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '用户名',
`password` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '密码',
`nickname` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '昵称',
`mobile` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '手机号码',
`email` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '邮箱',
`header` varchar(500) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '头像',
`gender` tinyint(4) UNSIGNED NULL DEFAULT 0 COMMENT '性别， 0男， 1女',
`status` tinyint(4) UNSIGNED NULL DEFAULT 0 COMMENT '启用状态：0正常，1锁定。',
`social_uid` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL COMMENT '社交用户在社交软件的id',
`create_time` datetime NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
`update_time` datetime NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
`level` tinyint(4) UNSIGNED NULL DEFAULT 1 COMMENT '用户等级。 0：管理员， 1：普通用户， 2：vip用户， 3：游客',
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `uniq_mobile`(`mobile`) USING BTREE,
UNIQUE INDEX `uniq_username`(`username`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '会员' ROW_FORMAT = Dynamic;
如果当前表中已存在数据，并且你添加了cdkey和erp_userid字段后，默认情况下这两个字段的值会是NULL。在这种情况下，将这两个字段合起来创建唯一索引不会立即引发任何冲突，因为NULL值在唯一索引中被视为不相同（即，多个NULL值在唯一索引中是允许的）。因此，即使多行的cdkey和erp_userid都是NULL，它们也不会违反新增的联合唯一索引规则。
但是，需要注意的是，一旦开始为这些字段插入非NULL值，就必须确保每一对（cdkey, erp_userid）的组合是唯一的，否则将会违反唯一索引约束，导致插入或更新操作失败。
要去掉 uniq_mobile 和 uniq_username 这两个唯一索引，你可以使用以下 SQL 语句：
-- 删除 uniq_mobile 索引
2ALTER TABLE `user`
3DROP INDEX `uniq_mobile`;
4
5-- 删除 uniq_username 索引
6ALTER TABLE `user`
7DROP INDEX `uniq_username`;
ALTER TABLE `session_chat_record`
ADD COLUMN `data_type` INT NOT NULL DEFAULT -1 COMMENT '数据类型' AFTER `update_time`;
ALTER TABLE `session_chat_record`
CHANGE COLUMN `data_type` `data_type` VARCHAR(20) NOT NULL DEFAULT '-1' COMMENT '数据类型';
-
ALTER TABLE `knowledge_base_help_center` ADD COLUMN `is_near` INT NOT NULL DEFAULT 0 COMMENT '是否相似问题 0-不是 1-是' AFTER `is_del`;
ALTER TABLE `knowledge_base_help_center`
ADD COLUMN `key_question` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '核心问题'
AFTER `is_del`;
ALTER TABLE `knowledge_base_help_center` ADD COLUMN `key_question` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '核心问题' AFTER `is_del`;
--------------------------------------------------------
utf8mb3 和 utf8mb3_general_ci 是MySQL数据库中用于字符集（Character Set）和排序规则（Collation）的术语。下面是对这两个术语的具体解释：
UTF8MB3 字符集
- UTF8MB3：这是MySQL早期版本中对UTF-8字符编码的支持方式，代表每个字符最多使用3个字节来存储。需要注意的是，尽管名称中包含"UTF8"，但实际上它并不是完整的UTF-8编码实现，因为它不支持4字节的UTF-8字符，比如一些表情符号和其他少见的Unicode字符。在MySQL 5.5及之后的版本中引入了
utf8mb4，以提供对完整UTF-8编码的支持，包括那些需要4字节存储空间的字符。
UTF8MB3_GENERAL_CI 排序规则
-
General：这指的是排序规则的一般性或通用性。在这种排序规则下，比较是基于字符的基本形态进行的，而不考虑大小写、重音等特性。这意味着例如字母“a”和“A”，或者带有不同重音标记的相同字母，在比较时可能会被视为相同。
-
CI：代表“Case Insensitive”，即不区分大小写的比较。这意味着在使用此排序规则时，“A”和“a”被认为是相同的。类似的，如果排序规则名中有“CS”，则表示“Case Sensitive”，即区分大小写；如果有“AI”，则表示“Accent Insensitive”，即不区分重音。
综上所述，utf8mb3_general_ci 表示使用utf8mb3字符集，并采用一种不区分大小写的通用排序规则。这种设置适合于大多数西方语言文本处理，但在处理需要4字节UTF-8编码的字符或需要严格区分大小写的情况时可能不是最佳选择。
如果你的应用程序需要支持更多类型的Unicode字符（如emoji表情），你可能需要考虑使用utf8mb4字符集及其相应的排序规则。
如果您想要优化您的数据库表定义，尤其是在选择字符集和排序规则时，考虑到utf8mb3的局限性（不支持4字节的UTF-8字符），推荐使用utf8mb4字符集。utf8mb4完全兼容并扩展了utf8mb3，它支持更广泛的字符集，包括emoji和其他需要4字节存储的Unicode字符。
以下是您原始SQL语句的一个优化版本，将字符集从utf8mb3改为utf8mb4，同时保持不区分大小写的通用排序规则(general_ci)：
ALTER TABLE `knowledge_base_help_center` ADD COLUMN `key_question` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '核心问题' AFTER `is_del`;
优化点解释
-
字符集更新：将
utf8mb3更新为utf8mb4，以确保对所有Unicode字符的支持，包括那些需要更多字节表示的字符（如表情符号）。 -
排序规则保持一致：继续使用
general_ci作为排序规则，以保持不区分大小写的特性。如果您希望在某些场景下区分大小写，可以考虑使用utf8mb4_bin或utf8mb4_unicode_ci等其他排序规则。
这种优化确保了您的应用能够处理更广泛的字符输入，增强了数据的完整性和用户体验，特别是对于国际化应用来说尤为重要。此外，由于现代MySQL版本都很好地支持utf8mb4，因此这是一个向前兼容的选择。
---------------------------------------------------------
UPDATE
// 单字段
update knowledge_base_faq_batch set update_time = '2025-01-22 14:30:00' where kid = 8;
// 多字段
update knowledge_base_faq_batch set update_time = '2025-01-22 14:30:00', is_del = 1 where kid = 9;
update knowledge_base_faq_batch_near_question set update_time = '2025-01-22 14:30:00' where id = 1;
update knowledge_base_faq_batch_near_question set update_time = '2025-01-22 14:30:00', is_del=1 where id = 2;
ALTER TABLE `session_chat_record`
ADD COLUMN `sub_data_type` varchar(20) COLLATE utf8mb4_bin NOT NULL DEFAULT '-1' COMMENT '子数据类型' AFTER `data_type`,
ADD COLUMN `sub_content` mediumtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL COMMENT '子对话内容' AFTER `sub_data_type`;
----------------------------------------------------------------------------------
ALTER TABLE `knowledge_questions` ADD COLUMN `publish_status` int NOT NULL DEFAULT '0' COMMENT '发布状态（见字典表：publish_status）' AFTER `function_permission`;
ALTER TABLE `knowledge_questions` ADD COLUMN `publication_date` timestamp NULL DEFAULT NULL COMMENT '发布日期' AFTER `publish_status`;
扫一扫
597
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
