189 8069 5689
UPDATE `wp_terms` SET `slug` = replace (`slug`,'+','')
创新互联公司网站建设服务商，为中小企业提供网站设计、成都网站制作服务，网站设计，网站托管、服务器托管等一站式综合服务型公司，专业打造企业形象网站，让您在众多竞争对手中脱颖而出创新互联公司。
没有问题的。
问题是你的这个列不允许重复。
你可以把重复的列找出来：
SELECT c.slug,count(*) FROM wp_terms c group by c.slug
其他的看你需求了。
step
1.将原来的gbk编码的数据库导出为utf8编码的(采用了gzip压缩)
#
/usr/local/mysql/bin/mysqldump
-uroot
-proot
–compatible=mysql40
–default-character-set=utf8
–extended-insert
–force
–add-locks
–add-drop-table
discuz
|
/usr/bin/gzip
-9
/home/ftp/backup/bak_1227.sql.gz
这里起主要作用的就是红色标出来的这两个选项了。
step
2.将网上的备份数据库文件下载到本地，解压
#
gunzip
bak_1227.sql.gz
导入到本地测试库wwwtest（手动创建的时候选的utf8_general_ci编码）中
#
/usr/local/mysql/bin/mysql
-uroot
-proot
wwwtest
/home/ftp/backup/bak_1227.sql
打开phpmyadmin查看一下数据库显示，数据库和表编码类型都是utf8_general_ci了，OK，大功告成。
————————————————————————————
这里需要注意的问题，导出时的文件编码,由于要导入到utf8编码的数据库中,并且导成utf8编码,所以添加参数–default-character-set=utf8,这样的话导出来的数据库备份文件就是utf8格式的文件了.还有另一个参数–compatible=mysql40,这个参数带上后就不会把原数据库中的编码设置导出来,比如我要导出的数据库是gbk编码的,如果不加–compatible=mysql40这个参数,那导出来的文件中创建表的语句中就会带有DEFAULT
CHARSET=gbk,如果这样的话导入数据时,即使数据库是utf8编码的,导入后表的编码也会变成gbk.所以要加–compatible=mysql40这条参数,这样就不会在数据库备份文件中带有DEFAULT
CHARSET=gbk,这样就可以导入到utf8编码的数据库中,而且导入的表也使用的是当前数据库的编码
首先，到mysql\bin 下面，利用mysqldump这个工具，执行以下命令：
mysqldump --u=root -p --default-character-set=latin1 --set-charset=utf8 --skip-opt --result-file=c:\mytable.sql mydb mytable
其中：root 为数据库登录名， latin1 为源表（就是想进行转码的表）的编码， utf8 为想转换成的编码， c:\mytable.sql 为导出的数据的存放文件（临时用）， mydb是源表所属的数据库（schema），mytable 就是源表名了
执行这条命令，会提示输入密码，输入正确的密码以后，就开始导出数据了。等到数据全部导出以后，可以用ue等工具打开，这时可以看到这些数据的编码已经转变了。
然后需要对这个文件进行一点点更改。在文件的最开头有一个建表语句。类似于：
Java代码
CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
);
注意看最后的分号，缺少了一点点东西：engine=myisam DEFAULT CHARSET=utf8 engine 和 charset 的意义地球人都知道啊... 将这一段加进去。结果可能是这样：
Java代码
CREATE TABLE `mytable` (
`tableid` bigint(20) unsigned NOT NULL,
`c1` int(10) unsigned NOT NULL default '0',
`c2` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`tableid`)
) engine=myisam DEFAULT CHARSET=utf8;
其中engine 和 charset 改成期望的东西，如：innodb gbk 等...
保存文件。（如果是用UE等工具即使文件大也不会等太久，如果用记事本打开的……恭喜你！ ）
这样就成功了一半了，剩下的工作只需要导入这个转好码的数据了。
将原来的那个表改名，一是为了备份，二是防止导入的时候说表已经存在。
然后还是进入mysql\bin 下面，运行：
Java代码
mysql -u root -p mydb c:\mytable.sql
输入密码以后程序开始工作，一段时间以后，新表就出来咯...
整理 MySQL 8.0 文档时发现一个变更：
默认字符集由 latin1 变为 utf8mb4。想起以前整理过字符集转换文档，升级到 MySQL 8.0 后大概率会有字符集转换的需求，在此正好分享一下。
当时的需求背景是：
部分系统使用的字符集是 utf8，但 utf8 最多只能存 3 字节长度的字符，不能存放 4 字节的生僻字或者表情符号，因此打算迁移到 utf8mb4。
迁移方案一1. 准备新的数据库实例，修改以下参数：[mysqld]## Character Settingsinit_connect='SET NAMES utf8mb4'#连接建立时执行设置的语句，对super权限用户无效character-set-server = utf8mb4collation-server = utf8mb4_general_ci#设置服务端校验规则，如果字符串需要区分大小写，设置为utf8mb4_binskip-character-set-client-handshake#忽略应用连接自己设置的字符编码，保持与全局设置一致## Innodb Settingsinnodb_file_format = Barracudainnodb_file_format_max = Barracudainnodb_file_per_table = 1innodb_large_prefix = ON#允许索引的最大字节数为3072（不开启则最大为767字节，对于类似varchar(255)字段的索引会有问题，因为255*4大于767）
2. 停止应用，观察，确认不再有数据写入
可通过 show master status 观察 GTID 或者 binlog position，没有变化则没有写入。
3. 导出数据
先导出表结构：mysqldump -u -p --no-data --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=OFF --databases testdb /backup/testdb.sql
后导出数据：mysqldump -u -p --no-create-info --master-data=2 --flush-logs --routines --events --triggers --default-character-set=utf8mb4 --single-transaction --set-gtid-purged=OFF --database testdb /backup/testdata.sql
4. 修改建表语句
修改导出的表结构文件，将表、列定义中的 utf8 改为 utf8mb4
5. 导入数据
先导入表结构：mysql -u -p testdb /backup/testdb.sql
后导入数据：mysql -u -p testdb /backup/testdata.sql
6. 建用户
查出旧环境的数据库用户，在新数据库中创建
7. 修改新数据库端口，启动应用进行测试
关闭旧数据库，修改新数据库端口重启，启动应用
MySQL 数字类型转换函数(concat/cast)。
1、将Int 转为varchar经常用 concat函数，比如concat(8,’0′) 得到字符串 ’80′。
2、将varchar 转为Int 用 cast(a as signed) a为varchar类型的字符串。
总结：类型转换和SQL Server一样,就是类型参数有点点不同 : CAST(xxx AS 类型) , CONVERT(xxx,类型)。
扩展资料：
可用的类型：
二进制,同带binary前缀的效果 : BINARY
字符型,可带参数 : CHAR()
日期 : DATE
时间: TIME
日期时间型 : DATETIME
浮点数 : DECIMAL
整数 : SIGNED
无符号整数 : UNSIGNED
cast函数运行示例
参考资料：mysql-百度百科