今天主要写mysql在centos下 通过命令导出 导入教程分享 服务器：商祺云服务器 – https://www.sq9.cn 开始： 备份： mysqldump -u数据库名 -p"密码" -h localhost 数据名 > /www/wwwroot/ceshi.com/aiqutui.sq（备份路径） 恢复命令： mysql -u数据名 -p"密码" -h localhost 数据名 < /www/wwwroot/ceshi.com/aiqutui.sql（恢复路径） 如何从A服务器搬迁到B服务器呢。那就需要scp命令了 scp file.txt remote_username@10.10.0.2:/remote/directory() 说明：file.txt 是我们要复制的文件名，remote_username 是远程服务器上的用户名，10.10.0.2 是服务器 IP 地址；/remote/directory 是要将文件复制到的目录的路径，如果不指定远程目录，文件将被复制到远程用户主目录 以上就是数据库搬迁导入教程、有运维问题 欢迎加QQ 690624
本篇文章给大家带来的内容是关于Mysql中utf8_unicode_ci、utf8_general_ci有什么区别？有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。 Mysql中utf8_general_ci与utf8_unicode_ci有什么区别呢？在编程语言中，通常用unicode对中文字符做处理，防止出现乱码，那么在MySQL里，为什么大家都使用utf8_general_ci而不是utf8_unicode_ci呢？ 用了这么长时间，发现自己竟然不知道utf_bin和utf_general_ci这两者到底有什么区别。。ci是 case insensitive, 即 "大小写不敏感", a 和 A 会在字符判断中会被当做一样的;bin 是二进制, a 和 A 会别区别对待.例如你运行:SELECT * FROM table WHERE txt = 'a'那么在utf8_bin中你就找不到 txt = 'A' 的那一行, 而 utf8_general_ci 则可以.utf8_general_ci 不区分大小写，这个你在注册用户名和邮箱的时候就要使用。utf8_general_cs 区分大小写，如果用户名和邮箱用这个 就会照成不良后果utf8_bin:字符串每个字符串用二进制数据编译存储。 区分大小写，而且可以存二进制的内容 一、官方文档说明下面摘录一下Mysql 5.1中文手册中关于utf8_unicode_ci与utf8_general_ci的说明： 当前，utf8_unicode_ci校对规则仅部分支持Unicode校对规则算法。一些字符还是不能支持。并且，不能完全支持组合的记号。这主要影响越南和俄罗斯的一些少数民族语言，如：Udmurt 、Tatar、Bashkir和Mari。 utf8_unicode_ci的最主要的特色是支持扩展，即当把一个字母看作与其它字母组合相等时。例如，在德语和一些其它语言中‘ß'等于‘ss'。 utf8_general_ci是一个遗留的 校对规则，不支持扩展。它仅能够在字符之间进行逐个比较。这意味着utf8_general_ci校对规则进行的比较速度很快，但是与使用utf8_unicode_ci的 校对规则相比，比较正确性较差）。 例如，使用utf8_general_ci和utf8_unicode_ci两种 校对规则下面的比较相等：Ä = AÖ = OÜ = U 两种校对规则之间的区别是，对于utf8_general_ci下面的等式成立：ß = s 但是，对于utf8_unicode_ci下面等式成立：ß = ss 对于一种语言仅当使用utf8_unicode_ci排序做的不好时，才执行与具体语言相关的utf8字符集 校对规则。例如，对于德语和法语，utf8_unicode_ci工作的很好，因此不再需要为这两种语言创建特殊的utf8校对规则。 utf8_general_ci也适用与德语和法语，除了‘ß'等于‘s'，而不是‘ss'之外。如果你的应用能够接受这些，那么应该使用utf8_general_ci，因为它速度快。否则，使用utf8_unicode_ci，因为它比较准确。 如果你想使用gb2312编码,那么建议你使用latin1作为数据表的默认字符集,这样就能直接用中文在命令行工具中插入数据,并且可以直接显示出来.而不要使用gb2312或者gbk等字符集,如果担心查询排序等问题,可以使用binary属性约束,例如: create table my_table ( name varchar(20) binary not null default '')type=myisam default charset latin1; 二、简短总结utf8_unicode_ci和utf8_general_ci对中、英文来说没有实质的差别。utf8_general_ci校对速度快，但准确度稍差。utf8_unicode_ci准确度高，但校对速度稍慢。 如果你的应用有德语、法语或者俄语，请一定使用utf8_unicode_ci。一般用utf8_general_ci就够了，到现在也没发现问题。。。 三、详细总结 1、对于一种语言仅当使用utf8_unicode_ci排序做的不好时，才执行与具体语言相关的utf8字符集校对规则。例如，对于德语和法语，utf8_unicode_ci工作的很好，因此不再需要为这两种语言创建特殊的utf8校对规则。2、utf8_general_ci也适用与德语和法语，除了‘?'等于‘s'，而不是‘ss'之外。如果你的应用能够接受这些，那么应该使用 utf8_general_ci，因为它速度快。否则，使用utf8_unicode_ci，因为它比较准确。 用一句话概况上面这段话：utf8_unicode_ci比较准确，utf8_general_ci速度比较快。通常情况下 utf8_general_ci的准确性就够我们用的了，在我看过很多程序源码后，发现它们大多数也用的是utf8_general_ci，所以新建数据 库时一般选用utf8_general_ci就可以了 四、如何在MySQL5.0中使用UTF8在 my.cnf中增加下列参数 [mysqld] init_connect='SET NAMES utf8′ default-character-set=utf8 default-collation = utf8_general_ci 执行查询 mysql> show variables; 相关如下: character_set_client | utf8 character_set_connection | utf8 character_set_database | utf8 character_set_results | utf8 character_set_server | utf8 character_set_system | utf8 collation_connection | utf8_general_ci collation_database |...
【腾讯云】2核2G云服务器新老同享 99元/年，续费同价，云服务器3年机/5年机限时抢购，低至 2.5折
2024-12-21
问题说明 如何对 ECS Linux 系统中部署的 MySQL 进行自动备份。 处理办法 在 ECS Linux 系统中搭建了 MySQL 服务，用户可以使用如下脚本实现 MySQL 的定期自动备份。 使用方法如下： 1. 将以下脚本拷贝到本地，上传到服务器上，名称叫 “autoback.sh” #!/bin/bash #-----------------------------------------------# #This is a free GNU GPL version 3.0 or abover #Copyright (C) 2008 06 05 #mysql_backup Dedicated copyright by My #-----------------------------------------------# echo -e [`date +"%Y-%m-%d %H:%M:%S"`] start #system time time=`date +"%y-%m-%d"` #host IP host="127.0.0.1" #database backup user user="root" #database password passwd="yourpasswd" #Create a backup directory mkdir -p /backup/db/"$time" #list database name all_database=`/usr/bin/mysql -u$user -p$passwd -Bse 'show databases'` #in the table from the database backup for i in $all_database do /usr/bin/mysqldump -u$user -p$passwd $i > /backup/db/"$time"/"$i"_"$time".sql done echo -e [`date +"%Y-%m-%d %H:%M:%S"`] end exit 0 脚本中的数据库名和数据库密码以用户需要备份的数据库信息为准，需要用户修改下。 2. 运行 crontab -e，写入以下内容： 30 5 * * * root sh /root/autobackup.sh >/dev/null...
问题描述 如何对 ECS Linux 系统中的 MySQL 进行备份的导入和导出。 处理办法 MySQL 备份的导出 MySQL 备份的导入 MySQL 备份的导出 注意： 如果您使用的是帮助中心的一键环境配置，那么 MySQL 的安装目录是 /alidata/server/mysql。 如果您将 MySQL 安装到其他目录，您需要输入您 MySQL 完整的安装路径。 单库备份您可以在服务器上执行如下命令： /alidata/server/mysql/bin/mysqldump -uroot -p密码 数据库名 > 备份名称.sql mysqldump 默认不会导出事件表，执行此命令会出现警告 — Warning: Skipping the data of table mysql.event. Specify the –events option explicitly. 如果您需要导出 MySQL 事件，您可以执行如下命令： /alidata/server/mysql/bin/mysqldump -uroot -p密码 --events --ignore-table=mysql.event 数据库名 > 备份名称.sql MySQL 备份的导入 如果您需要导入备份的 .sql 文件，可以在 备份名称.sql 文件所在目录中执行如下命令： /alidata/server/mysql/bin/mysql -uroot -p密码 mysql < 备份名称.sql 也可以通过执行如下命令： /alidata/server/mysql/bin/mysql -uroot -p密码 mysql>use 数据库; mysql>source /root/备份名称.sql; 注意：/root/备份名称.sql 为实际备份文件绝对路径 以上就是Linux系统MySQL备份的导入导出的具体分析的详细内容，更多请关注学派吧-其它相关文章！
前言 mysqldump是mysql用于转存储数据库的实用程序。它主要产生一个SQL脚本，其中包含从头重新创建数据库所必需的命令CREATE TABLE INSERT等。 1. 常用参数 2. mysqldump 默认参数 3. mysqldump 常用方法 mysqldump是MySQL数据库自带的一款命令行工具，mysqldump属于单线程，功能是非常强大的，不仅常被用于执行数据备份任务，甚至还可以用于数据迁移。 备份粒度相当灵活，既可以针对整个MySQL服务，也可以只备份某个或者某几个DB，或者还可以指定只备份某个或者某几个表对象，甚至可以实现只备份表中某些符合条件的记录。 mysqldump命令创建的是逻辑备份，它输出的结果集有两种格式：一种是将数据转换成标准SQL语句（一堆 CREATE , DROP ，INSERT等语句）；另一种是将数据按照指定的分隔符，输出成定界格式的平面文件。 mysqldump 使用参数很多，但是实际上经常用到的并没有多少。下面我们来介绍一下这些参数： mysqldump 具体有多少参数，我们可以使用 $ mysqldump --help 命令查看 1. 常用参数 -?, –help: 显示帮助信息，英文的； -u, –user: 指定连接的用户名； -p, –password: 指定用户的密码，可以交互输入密码； -S , –socket: 指定socket文件连接，本地登录才会使用。 -h, –host: 指定连接的服务器名称或者IP。 -P, –port=: 连接数据库监听的端口。 –default-character-set: 设置字符集，默认是UTF8。 -A, –all-databases: 导出所有数据库。不过默认情况下是不会导出information_schema库。 -B, –databases: 导出指定的某个/或者某几个数据库，参数后面所有名字参量都被看作数据库名，包含CREATE DATABASE创建库的语句。 –tables: 导出指定表对象，参数格式为“库名 表名”，默认该参数将覆盖-B/–databases参数。 -w, –where: 只导出符合条件的记录。 -l, –lock-tables: 默认参数，锁定读取的表对象，想导出一致性备份的话最后使用该参数，会导致无法对表执行写入操作。 –single-transaction: 该选项在导出数据之前提交一个BEGIN SQL语句，BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于多版本存储 引擎，仅InnoDB。本选项和–lock-tables 选项是互斥的，因为LOCK TABLES 会使任何挂起的事务隐含提交，使用参数–single-transaction会自动关闭该选项。 在InnoDB导出时会建立一致性快照，在保证导出数据的一致性前提下，又不会堵塞其他会话的读写操作，相比–lock-tables参数来说锁定粒度要低，造成的影响也要小很多。指定这个参数后，其他连接不能执行ALTER TABLE、DROP TABLE 、RENAME TABLE、TRUNCATE TABLE这类语句，事务的隔离级别无法控制DDL语句。 -d, –no-data: 只导出表结构，不导出表数据。 -t, –no-create-info: 只导出数据，而不添加CREATE TABLE 语句。 -f, –force: 即使遇到SQL错误，也继续执行，功能类似Oracle exp命令中的ignore参数。 -F, —flush-logs: 在执行导出前先刷新日志文件，视操作场景，有可能会触发多次刷新日志文件。一般来说，如果是全库导出，建议先刷新日志文件，否则就不用了。 –master-data[=#]: 该选项将二进制日志的位置和文件名写入到输出中。该选项要求有RELOAD权限，并且必须启用二进制日志。如果该选项值等于1，位置和文件名被写入CHANGE MASTER语句形式的转储输出，如果你使用该SQL转储主服务器以设置从服务器，从服务器从主服务器二进制日志的正确位置开始。如果选项值等于2，CHANGE MASTER语句被写成SQL注释。如果value被省略，这是默认动作。 –master-data选项会启用–lock-all-tables，除非还指定–single-transaction(在这种情况下，只在刚开始转储时短时间获得全局读锁定。又见–single-transaction。在任何一种情况下，日志相关动作发生在转储时。该选项自动关闭–lock-tables。 所以，我在INNODB引擎的数据库备份时，我会同时使用–master-data=2 和 –single-transaction两个选项。 -x, –lock-all-tables: 在导出任务执行期间锁定所有数据库中的所有表，以保证数据的一致性。这是一个全局锁定，并且自动关闭–single-transaction 和–lock-tables 选项。这个参数副作用比较大，这是全库锁定，备份执行过程中，该库无法进行读写操作，不是所有业务场景都能接受的。请慎用。 -n, –no-create-db: 不生成建库的语句CREATE DATABASE … IF EXISTS，即使指定–all-databases或–databases这类参数。 –triggers: 导出表的触发器脚本，默认就是启用状态。使用–skip-triggers禁用它。 -R, –routines: 导出存储过程以及自定义函数。...
有需要服务器方面的需求和咨询，可以联系博主 QQ 7271895 本来MySQL BINLOG和SHOW PROCESSLIST命令属于八竿子打不着的两个事务，但在最近故障排查中，发现主库和从库已经存在很严重的复制延迟，但从库上显示slave_behind_master值为0，复制SQL线程与备份线程之间相互阻塞，但未报死锁 在从库上执行SHOW PROCESSLIST发现复制的SQL线程等待锁，而等待SQL的WHERE条件竟然是类似于WHERE C1=’ABC’ AND C2>’2018-03-01′ AND C2<‘2018-03-26’ 这种个范围查询，第一时间想到就是怎么是个基于STATEMENT的复制，不科学啊，我们生产环境统一使用基于ROW格式的复制，难道研发私自修改回话级别的复制格式？ 使用MySQL Binlog导出日志一看： 发现真错怪研发同事啦，rbr_only=yes说明基于ROW格式进行复制，“SET TRANSACTION ISOLATION LEVEL READ COMMITTED”也是基于行格式复制的典型特征之一，last_committed和sequence_number用于MySQL 5.7版本中的并发复制，row_query后跟的是在主库上执行的原始SQL，也就是我们在从库SHOW PROCESSLIST中看到的SQL，但实际上从库执行的还是BINLOG部分，该BINLOG可以直接可以直接直接在从库上执行，也可以解析成一行行的数据DML操作，BINLOG部分如下： ========================================================================================================== 另外一个很有意思的问题，如果在从库上运行mysqldump进行备份，且从库上使用并行复制，会导致备份和复制相互阻塞： 在上面的阻塞中，多个SQL线程与备份线程相互之间阻塞，且MySQL无法有效检测出死锁环路而触发死锁的回滚机制，导致复制线程和备份作业相互hang住，需要DBA进行干预（取消备份或停止复制），在复制SQL线程被hang住期间，复制的IO线程仍可以正常工作接受到主库的Binlog信息，但slave_behind_master并不会随之增大，如果仅通过监控slave_behind_master值来判断主从复制延迟，则会导致延迟监控存在严重漏洞，因此在监控复制延迟时，除监控slave_behind_master值外，还需要监控主库binlog位置点和从库执行的binlog位置点。 如果有不懂的、欢迎加入我们学派吧。一起学习交流。右上角站长群
