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-百度百科