分类 MySQL 下的文章

2022-12-30

Mysql数据表生成文档表结构，导出并生成word文档的方法因为项目需要编写库表结构word文档，需要交付验收，下面给大家介绍一种我用的方式步骤一：使用sql生成表结构数据SELECT ORDINAL_POSITION 序号, COLUMN_NAME 列名, COLUMN_TYPE 数据类型, -- COLUMN_DEFAULT 默认值, (CASE IS_NULLABLE WHEN 'NO' THEN '否' WHEN 'YES' THEN '是' ELSE '' END) 允许为空, COLUMN_KEY 主键, COLUMN_COMMENT 注释 FROM information_schema.`COLUMNS` WHERE TABLE_SCHEMA='dbname' -- 库名 AND table_name='table_demo' -- 表明步骤二：使用Navicat Premium工具导出Excle我们将查询成功的数据导出Excel，并将内容复制到doc中即可有其它更好方式的可以推荐下哦，虽然这个方法步骤有点多，但是总比一个个复制要好些，写代码动手能力比较强的伙伴，可以考虑使用上面的sql查询代码来生成表格，然后用代码生成word文档，navicat premium破解版获取点击： navicat premium破解版下载

2022年12月30日
226 阅读
0 评论
0 点赞

2022-04-18

linux 定时任务备份至七牛场景生产数据定时备份的意义大家应该都是知道的，很多人备份只是备份到了本地，但是也会存在一定的隐患，比如客户一直不用系统，我们也不去注意，哪天服务器到期了过了几个月客户突然要用方向数据没了。。。使用到的工具主要看大家的服务器的安装情况，如果是安装了宝塔面板这种，有定时任务工具直接使用，而且也有免费的七牛云插件，设置起来超级简单，如果安装宝塔的不懂设置可以评论区留言，实在是太简单了本文就不讲了，说实话是会点鼠标就可以弄了基于linux系统内备份大概的意思就是你的mysql是自己用命令安装的。七牛平台shell脚本linux定时任务需要七牛云账号，用户需要自己创建，或者其它用其它云盘原理都是一样的（一）下载qshell工具并安装设置1. 工具下载说明文档与下载地址：七牛工具下载工具是七牛官方提供的，下载工具后传到服务器，主要看自己服务器的架构，我的服务是linux x86的，根据自己服务器去下载，把文件上传至服务目录/home/backup/shell 目录。并赋予权限chomd +x qshell2. 登录设置七牛云账号注意需要在工具目录下执行，如果需要任何目录执行需要添加环境变量可查看官方文档说明，更多说明以官方最新文档为准# 参数说明可自己根据情况修改 #ak :官方获取 #sk: 官方平台获取 #name : 任意用户名，不是七牛的账户，比如 db-test qshell account <ak> <sk> <name> #完成命令参考（二） shell编辑脚本在目录/home/backup/shell 下新建脚本backup.sh#!/bin/sh # mysql data backup script # # use mysqldump --help,get more detail. # 需要设置环境变量，crond中默认读取不到我们的一些环境 PATH=$PATH:/home/backup/shell export PATH dbname=<dbname> #备份文件目录 bakDir=/home/backup/sql logFile=/home/backup/backup.log month=` date +%Y%m ` # 七牛的备份目录，当前按数据库为一级目录，月份为2级目录如：dbname/202004/****.gz.sql qiniuPath=typecho_joe_theme/$month # 七牛空间名 qiniuBucket=<bucketName> datetime=`date +%Y%m%d%H%M%S` keepDay=7 echo "-------------------------------------------" >> $logFile echo $(date +"%y-%m-%d %H:%M:%S") >> $logFile echo "--------------------------" >> $logFile cd $bakDir bakFile=$dbname.$datetime.sql.gz # yum,apt-get,源码编译安装释放 mysqldump -u$user -p$password $dbname | gzip > $bakFile #docker安装执行方式,需要修改<dbname>为自己的数据库 #docker exec mysql5.6 sh -c 'exec mysqldump <dbname> -uroot -p"$MYSQL_ROOT_PASSWORD"' | gzip > $bakDir/$bakFile echo "数据库 [$dbname] 备份完成" >> $logFile echo "$bakDir/$bakFile" >> $logFile echo "开始上传备份文件至七牛云存储" >> $logFile #七牛上传命令，分片上传适用大文件，当前使用低频储存，具体命令可以查看文档 qshell rput $qiniuBucket $qiniuPath/$bakFile $bakDir/$bakFile --storage 1 | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" >> $logFile 2>&1 echo "删除${keepDay}天前的备份文件" >> $logFile find $bakDir -ctime +$keepDay >> $logFile find $bakDir -ctime +$keepDay -exec rm -rf {} \; echo " " >> $logFile echo " " >> $logFile 参考文献：qshell命令说明rput 操作说明（二）添加定时任务需要使用到cron命令，本文不展开讲这个，需要了解的可以参考以下文献文献一： crontab配置方法文献二： Linux系统crontab定时任务的配置概要与常见问题文献三： crontab 与环境变量下面直说具体操作，执行器需要先检查crond的状态service crond status，如果是在运行中就没什么问题编辑定时任务#修改当前用户定时任务 crontab -e 添加任务脚本，操作和vi是一样的# 每天凌晨3点执行脚本， 0 3 * * * /home/backup/backup.sh # 如果是测试可以用以下的脚本,意思是没2分钟执行一次，看看有没有成本 */2 * * * * /home/backup/backup.sh查看定时任务#查看当前任务情况 crondtab -l（三）完成设置完成以后最好要检查下是否成功，建议先设置按分钟执行备份看看，如果中间有什么问题要多百度，一般都可以搜得到

2022年04月18日
88 阅读
0 评论
0 点赞

2022-04-17

【MySql】Specified key was too long; max key length is 767 bytes的解决方案问题背景由于业务需要，需要做数据库迁移，迁移由5.7版本得mysql到现有的mysql5.6版本，主要是因为更innodb_large_prefix 参数有关由于MySQL的InnoDB引擎表索引字段长度的限制为767字节，因此对于多字节字符集的大字段或者多字段组合，创建索引时会出现该问题。在5.6中innodb_large_prefix 默认关闭，在5.7中默认开启。在5.6中默认为 offSpecified key was too long; max key length is 767 bytes原来是主键的长度太长，最大长度仅支持767字节，注意，这里的是字节。那么，我定义一个主键是varchar(500)的字段，不管我使用utf8编码，那么500字符长度将占用5003的字节长度（utf8最多支持3个字节长度）；或是我使用utf8mb4编码，那么500字符长度将占用5004的字节长度（utf8mb4最多支持4个字节长度），都大大超过了767字节。如何去解决呢？先检查一下是不是数据库被限制了索引的大小，查询innodb_large_prefix这个字段，这个字段限制了索引前缀的大小。关闭此限制后，索引前缀的大小将可以达到3072字节。方法1：修改全局变量修改全局变量，当mysql重启后将失效，建议直接修改配置文件SHOW variables like 'innodb_large_prefix';如果查询的值是OFF的话执行下面命令SET GLOBAL INNODB_LARGE_PREFIX = ON;另外，innodb_large_prefix这个属性在5.6上是默认关闭的，而在5.7上是默认开启的。执行完了之后还得查看当前的innodb_file_format引擎格式类型是不是BARRACUDA执行SHOW variables like 'innodb_file_format';如果不是的话则需要修改SET GLOBAL innodb_file_format = BARRACUDA;方法二：修改配置[mysqld] innodb_large_prefix = on innodb_file_format = BARRACUDA最后，创建表的时候，还需要指定表的 row format 格式为 Dynamic 或者 Compressed，如下示例：CREATE TABLE test( name varchar(500) CHARACTER SET utf8 COLLATE utf8_bin, PRIMARY KEY (`name `) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;版权声明：本文为CSDN博主「SunAlwaysOnline」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。参考原文链接：https://blog.csdn.net/qq_33591903/article/details/103927547

2022年04月17日
254 阅读
0 评论
0 点赞

2022-04-06

2022年04月06日
104 阅读
0 评论
0 点赞

2022-04-06

关于MYSQL中BINLOG_FORMAT的三种模式 MYSQL中BINLOG_FORMAT的三种模式mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。① STATEMENT模式（SBR）每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)② ROW模式（RBR）不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。③ MIXED模式（MBR）以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。binlog复制配置在mysql的配置文件my.cnf中，可以通过一下选项配置binglog相关代码如下复制代码binlog_format = MIXED //binlog日志格式，mysql默认采用statement，建议使用mixedlog-bin = /data/mysql/mysql-bin.log //binlog日志文件expire_logs_days = 7 //binlog过期清理时间max_binlog_size = 100m //binlog每个日志文件大小binlog_cache_size = 4m //binlog缓存大小max_binlog_cache_size = 512m //最大binlog缓存大小三 MIXED说明对于执行的SQL语句中包含now()这样的时间函数，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。现在来比较以下 SBR 和 RBR 2中模式各自的优缺点：SBR 的优点：历史悠久，技术成熟binlog文件较小binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况binlog可以用于实时的还原，而不仅仅用于复制主从版本可以不一样，从服务器版本可以比主服务器版本高SBR 的缺点：不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。调用具有不确定因素的 UDF 时复制也可能出问题使用以下函数的语句也无法被复制：LOAD_FILE()UUID()USER()FOUND_ROWS()SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)INSERT ... SELECT 会产生比 RBR 更多的行级锁复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事确定了的 UDF 也需要在从服务器上执行数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错执行复杂语句如果出错的话，会消耗更多资源RBR 的优点：任何情况都可以被复制，这对复制来说是最安全可靠的和其他大多数数据库系统的复制技术一样多数情况下，从服务器上的表如果有主键的话，复制就会快了很多复制以下几种语句时的行锁更少：INSERT ... SELECT包含 AUTO_INCREMENT 字段的 INSERT没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句执行 INSERT，UPDATE，DELETE 语句时锁更少从服务器上采用多线程来执行复制成为可能RBR 的缺点：binlog 大了很多复杂的回滚时 binlog 中会包含大量的数据主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题UDF 产生的大 BLOB 值会导致复制变慢无法从 binlog 中看到都复制了写什么语句当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生另外，针对系统库 mysql 里面的表发生变化时的处理规则如下：如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都采用 SBR 模式记录注：采用 RBR 模式后，能解决很多原先出现的主键重复问题。原文转载：https://www.cnblogs.com/xingyunfashi/p/8431780.html

2022年04月06日
76 阅读
0 评论
0 点赞